git merge after git cherry-pick: avoiding duplicate commits

Sat, 2008-09-27

Imagine we have the master branch and a branch b:

  o---X   <-- master
   \
    b1---b2---b3---b4   <-- b

Now we urgently need the commits b1 and b3 in master, but not the remaining commits in b. So what we do is checkout the master branch and cherry-pick commits b1 and b3:

$ git checkout master
$ git cherry-pick “b1’s SHA”
$ git cherry-pick “b3’s SHA”

The result would be:

  o---X---b1'---b3'   <-- master
   \
    b1---b2---b3---b4   <-- b

Let’s say we do another commit on master and we get:

  o---X---b1'---b3'---Y   <-- master
   \
    b1---b2---b3---b4   <-- b

If we would now merge branch b into master:

$ git merge b

We would get the following:

  o---X---b1'---b3'---Y--- M  <-- master
   \                     /
     b1----b2----b3----b4   <-- b

That means the changes introduced by b1 and b3 would appear twice in the history. To avoid that we can rebase instead of merge:

$ git rebase master b

Which would yield:

  o---X---b1'---b3'---Y   <-- master
                       \
                        b2---b4   <-- b

Finally:

$ git checkout master
$ git merge b

gives us:

  o---X---b1'---b3'---Y---b2---b4   <-- master, b

Reference: http://kerneltrap.org/mailarchive/git/2008/7/23/2648694