git merge after git cherry-pick: avoiding duplicate commits

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

Merging with vimdiff

Open the files with vimdiff:
$ vimdiff file1 file2

To jump to the next difference:
]c

To jump to the previous difference:
[c

If there are only two files you can copy differences with:
:diffget
and
:diffput

If you are doing a diff with vim between more than two files you also have to specify from which buffer to :diffget or from which buffer to :diffput
:diffget b#
where b# is the buffer number. In vertical window split, buffers are numbered from left to right starting at 1.