Re: git merge and cherry-pick and duplicated commits?

From: Brian Gernhardt <benji@silverinsanity.com>
Date: Jan 14, 2009, 05:31 UTC
Message-ID: <5EA96780-EF4C-4B31-9C60-6ABAF21663FA@silverinsanity.com>
In-Reply-To: <2729632a0901131840v5c7ce0c7l3f87c03caabf68de@mail.gmail.com>

On Jan 13, 2009, at 9:40 PM, skillzero@gmail.com wrote:

Show 6 quoted lines

> I created a branch from master, did a commit (8e9fdd), then did 2 more
> commits (11c59c and 7024d), then did another commit (2daf23). From
> master, I did a commit (47bd1b) then cherry-pick'd 2 commits from the
> branch (11c59c and 7024d). When merged the branch into master, I see
> the 2 cherry-picked commits twice in the log (once from the original
> cherry-pick's and again from the merge).

Before the cherry-picks, your repository looks like this

o-o (master: 47bd1b)
  \
   o-A-B-o (branch:2daf23)

A and B are the two commits you cherry-picked (11c59c and 7024d)

After the cherry-picks, the repo looks like this:

o-o-A'-B' (master)
  \
   o-A-B-o (branch:2daf23)

A and A' are different commits. Same with B and B'. If you check the SHA1 of master at this point, it will NOT be 702fd... (B). Cherry pick creates a new commit that (as far as git is concerned) is totally unrelated.

After the merge, you get:

o-o-A'-B'-o (master)
  \       /
   o-A-B-o

Since git has no knowledge that the cherry-picked (A' B') commits are related to their originals (A B), it displays both to you. If you want, you can use the -x flag when you use "git cherry-pick" to add a line that describes the original source of the patch in the new commit which eases confusion when you look at the history, but will not stop them from being displayed.

(The reason git will still display them is that the cherry-picked commits may be different if there were conflicting changes on the branches. Also, hiding those commits would give a false view of history since the changes were actually added to the repository twice. Using gitk or "git log --graph" will show the commits on two different lines of development.)

> I thought git would realize that master already had those 2 commits
> and not add them again when merging?

The simplest method is to rebase branch after doing the cherry-picks. This should only be done if your branch has not been published. From after the cherry-picks:

o-o-A'-B' (master)
  \
   o-A-B-o (branch:2daf23)

"git rebase master branch" would give you

o-o-A'-B' (master)
         \
          o'-o' (branch)

Git should detect that the changes from A and B were already present in master during the rebase and skip the commits.

~~ Brian Gernhardt