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

From: Ted Ts'o <tytso@mit.edu>
Date: Sep 14, 2010, 16:49 UTC
Message-ID: <20100914164917.GA3730@thunk.org>
In-Reply-To: <4C8F99FA.3040003@workspacewhiz.com>

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