Re: Coping with the pull-before-you-push model

[Ted Ts'o <tytso@mit.edu>]

On Tue, Sep 14, 2010 at 09:51:22AM -0600, Joshua Jensen wrote:
> How does the integration with Gerrit work here?  The only thing that
> comes to mind is that you do something like:
> 
> git push gerrit HEAD:refs/for/merged-master

So we'll push to something to, say, refs/heads/fs/ext4/for-merged on
the gerrit server, and let gerrit do its thing.  After a colleague
approves all of the patches in the branch, gerrit will release the
commits to the branch, and only then will the mergitator script
attempt to do a trial merge of the effort branch with the
merged/master branch.  If the trial merge succeeds, then it will
attempt to do a trial compile.  If the trial compile succeeds then the
merged/master branch will be updated with the commit id of the trial
merge, and then the mergitator script will move on to the next effort
branch will has been updated.  If the mergitator fails to merge a
particular branch, then an e-mail is sent out explanining the cause of
the merge failure, so a human can fix things up.  This could be done
by cherry-picking a commit from merged/master which caused the merge
conflict, and then fixing up the merge conflict, for example.

A wise developer will do a trial merge on their own *before*
submitting their effort branch to gerrit for code review, but this is
not strictly speaking required.

						- Ted