[Insight-developers] git process - merging in master before push to gerrit

[Michael Stauffer (Circular Logic)]

Thanks for the clarifications, Brad. I'll share this info with the other
developers here at Penn - we're working on clarifying best-practices
that we should use.

Cheers,
Michael  

>-----Original Message-----
>From: Brad King [mailto:brad.king at kitware.com] 
>Sent: Monday, November 29, 2010 8:23 AM
>To: Michael Stauffer (Circular Logic)
>Cc: 'ITK-dev-list'
>Subject: Re: [Insight-developers] git process - merging in 
>master before push to gerrit
>
>On 11/24/2010 09:20 PM, Michael Stauffer (Circular Logic) wrote:
>> Should we always rebase like this with origin/master before 
>pushing to
>> gerrit?
>
>In general this is not necessary.  It is prudent if you suspect there
>may be conflicting work in master since you started your topic.
>
>If you made many commits of partially completed work then you should
>typically rebase to edit the commits and organize them into logically
>distinct incremental changes (for easier review).  However, the new
>base can just be the same as the old base in that case.
>
>> Seems reasonable, since it makes sure our changes work. But if
>> somethings broken in an origin/master commit that was made since we
>> branched, our change may fail. Do we wait for a fix on that 
>or push up
>> our change based on its original original/master branch point?
>
>This is one reason to not rebase if you do not need to do so.  It will
>be easier for a reviewer to compile/test your changes if they 
>are always
>based on an otherwise working version.
>
>> Similarly, after a change has been reviewed and accepted, 
>the wiki says
>> to just git gerrit-merge it. So in this case we don't need 
>to rebase on
>> origina/master to check for problems first?
>
>Most of the time work is independent and the merged version 
>will be okay.
>If there are merge conflicts the gerrit-merge will print instructions
>to merge master into your topic first.  Yes, there are 
>pathological cases
>where there can be a conceptual or logic conflict that does 
>not manifest
>itself as a content conflict, but it is not worth extra steps for every
>topic to handle the rare case.
>
>-Brad