On Wednesday, February 16, 2011 13:45:46 Stefan Majewsky wrote: > On Tue, Feb 15, 2011 at 6:51 PM, Aaron J. Seigo <ase...@kde.org> wrote: > > Only features / topics that are intended from the state to be merged > > with > > master should end up in the main repository, however. More experimental > > and/or long term efforts (an example presented was the kconfig refactor > > leading up to 4.0) should start in a personal clone, and when/if the > > work crosses the border into "this is realistically going to be merged > > with master" it can be moved into a branch in the main repository. > > As far as I'm concerned, the only problem with such branch moves is > the potentially epic number of commit notification mails. If so, the > email hook should check if the push generates a new branch, and send > only one mail then, like "100 commits have been pushed into the new > branch foobar; see >>here<< for a complete log vs. master and >>here<< > for the diff".
This actually came up elsewhere in the meeting as well. There are two major proposed methods on integrating a feature development branch back into master when ready. 1. You can use git-merge in order to merge 2 or more branches into a single commit. The resulting commit is essentially just a normal commit with more than one parent. Because of this, it is possible for git to verify that every commit in history of each parent is present, and more importantly for this problem, there is no duplication of commit emails (since there's only the 1 new commit). A disadvantage is that it can clutter the output of GUI (and CLI) based tools, especially if there are multiple active branches in development at once. 2. You can use git-rebase to basically reapply the diff for every commit in a given branch off of a different base commit. For example: * - A - G - H - I - J - K master \ - B - C - D - E - F solid/make-it-cool In this history tree make-it-cool and master have both diverged from A. If git-rebase were run to integrate make-it-cool into master, the result would look something like: * - A - G - H - I - J - K - B' - C' - D' - E' - F' master Every commit is still there. However, B', C', etc. are logically *new* commits that were created by git-rebase, but with the same commit message (the commit itself would be generated by generating the diff between the original commit and its parent, and then re-applying on the new parent). Since we're generating new commits anyways, it is also possible to "clean up" the history upon integration (e.g. merge logically related commits C' and D' into C', or split a too-large commit E' into E1' and E2'). However since they are new commits, they would also result in new commit emails being sent, which could be quite the disaster for large branches. In addition some of those re-sent commit emails might try to duplicate previously taken actions for no reason (e.g. a needless CCMAIL: or GUI:). An easy way to solve duplicates is to disable sending commit mails for branches other than master, but I personally dislike that solution as it would result in mailing lists like #kde-commits not receiving any emails until the branch is fully landed on master. (I hate to say it, but imagine a security mistake on ksslsocket.cpp in commit 88 of a 121-commit rebase branch -- is everyone on #kde-commits going to review that deeply into the commit chain?) There may be a way to allow emails on branches and still filter out duplicates upon merging, but the sysadmins (IIRC) didn't know of a way to do it offhand. In addition as Andreas Pakulat mentioned in a response to a rebase-workflow in kde-scm-interest, this completely deletes the fact that the development happened in a branch at all (we could simply retain the old solid/make-it-cool ref so we don't lose that history, but that would make the repository correspondingly larger). A lot of this debate hinges on how we want email-based review to work however (to be clear, kde-commits is *not* the only recipient of email for each git commit, the CIA.vc web service also receives email for each commit). If we want to avoid huge email bombs then we need to either use a merge-based workflow in general, or have some other technical solution to allow for a rebase-based workflow, such as your idea regarding lumping everything into a simple notification email (although this means CIA.vc and possibly things like Commit Filter wouldn't work... :( ) Regards, - Michael Pyne
signature.asc
Description: This is a digitally signed message part.