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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]