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

[Michael Stauffer (Circular Logic)]

Thanks Brad, I'll do this. I think I understand rebasing much better
now.

Should we always rebase like this with origin/master before pushing to
gerrit? 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?

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?

Cheers,
Michael

>-----Original Message-----
>From: Brad King [mailto:brad.king at kitware.com] 
>Sent: Tuesday, November 23, 2010 3:43 PM
>To: Michael Stauffer (Circular Logic)
>Cc: 'ITK-dev-list'
>Subject: Re: [Insight-developers] git process - merging in 
>master before push to gerrit
>
>On 11/23/2010 03:32 PM, Michael Stauffer (Circular Logic) wrote:
>> A git/gerrit question. Say I'm on a topic branch for more than a few
>> hours or day. I make my changes and test, then merge in from
>> origin/master to test against the latest changes from master. 
>> 
>> Assuming my changes still work, do I then push directly from 
>this topic
>> branch to gerrit, or do I pull out my changes into a new 
>branch based on
>> the latest master so the history's a little cleaner? 
>> 
>> If I need to pull out my changes, what's an efficient way to 
>do that if
>> I've modified existing files, and not just added new ones? 
>Use git patch
>> and apply it to a clean branch based on the latest master?
>
>Rebase your whole topic on the latest master:
>
> $ git checkout my-topic
> $ git fetch origin
> $ git rebase origin/master
>
>Topics under review in Gerrit should have no merges.
>
>-Brad