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

[Brad King]

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