git workflow draft

[Michael Pyne]

On Wednesday, February 16, 2011 13:45:46 Stefan Majewsky wrote:
> On Tue, Feb 15, 2011 at 6:51 PM, Aaron J. Seigo <aseigo at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110216/12ad51e7/attachment.sig>