Re: Ignoring commits when merging

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Mike Strauch wrote:

> I'm fairly new to git and I'm trying to figure out the best way to
> ignore certain commits when merging one branch into another.

An interesting question.  The answer (as so often) depends on what
you want to do.  "man 7 gitworkflows" might help.

Below I will pretend you are trying to backport some changes to a more
stable branch; others may chime in with other scenarios.

First, a general hint: when using git and similar systems, it is
generally best if each merged result is somehow "better" than all of
its parents.  I will give an example below of what can go wrong if
this invariant is violated.

Merging to a maintenance branch
-------------------------------

Suppose given a history like this (1):

 o --- v1.0 [maint]
           \
            feature --- feature --- bugfix --- bugfix [master]

Development has been happening on the "master" branch and now you
want to merge back the relevant fixes to make a new point release,
something like the following:

[*] o --- v1.0 ------------------------------------ v1.1 [maint]
              \                                    /
               master-only feature --- bugfix --- M [master]

  "a dangerous history"

Let's consider what that would mean.  Someone builds some new
work off of maint:

 o --- v1.0 --- v1.1 --- o ... o --- A [someone]
               /

What happens when you pull the "someone" branch into master?  The
relevant piece of history looks like this:

        v1.1 --- o ... o --- A [someone]
       /
  ... M --- new development --- ... --- B [master]

When you try to pull A into B, git runs a three-way merge to
apply the changes from the someone branch after the branch point (M)
on the master branch.  In particular, the changes from M to v1.1
are pulled in.  The main change from M to v1.1 is to drop a
bunch of features.  So by pulling from someone, you lose features
on the master branch.

So a merge like [*] that drops desirable changes is generally not
a good idea.

Cherry-picking to a maintenance branch
--------------------------------------

As a result, starting from a history like (1), there is only one
choice: cherry-pick only the bugfixes, so the new features are not
incorporated into the history of the maint branch.

 $ git checkout maint
 $ git cherry-pick bugfix1 bugfix2

Afterwards, it is best to merge the maint branch into master, so
later changes on the maint branch can be merged into master more
easily.  Usually despite the duplicate changes will not result in
conflicts.

 $ git checkout master
 $ git merge maint
 $ git diff HEAD^
 $ : looks good
 $ git push public maint master

If there are conflicts, no need to worry: make sure that "master"
really includes all desirable changes from maint and merge with
strategy ours instead.

 $ git reset --merge
 $ git merge -s ours maint

Writing a new bugfix
--------------------

Suppose you have an idea for a new bugfix.  As discussed above, if
you write it directly on top of master, when it is time to apply
it to maint it will need cherry-picking.  If you base the patch
on maint, you can avoid that:

 $ git checkout -b bugfix maint
 ... hack hack hack ...
 $ make test
 $ : looks good
 $ git checkout master
 $ git merge bugfix
 $ make test
 $ git push public bugfix master

 v1.1 [maint] --- X [bugfix]
     \             \
      o --- ... --- N [master]


Once the patch gets enough testing from users of master, it is
time to apply it to maint.

 $ git checkout maint
 $ git merge bugfix
 $ make test
 $ git checkout master
 $ git merge maint
 $ git push public maint master

 v1.1 ----------- X [maint]
     \             \
      o --- ... --- N [master]

One benefit of this approach is that during development, the patch
is tested against the maintenance branch, which is incidentally
probably where it is most important that it get testing.

Hope that helps,
Jonathan