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

From: Thomas Rast <trast@student.ethz.ch>
Date: Jan 14, 2009, 08:41 UTC
Message-ID: <200901140941.17110.trast@student.ethz.ch>
In-Reply-To: <2729632a0901132221r746144a1y9628615be1c6ad04@mail.gmail.com>

skillzero@gmail.com wrote:

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

[later]

> That's what I was somewhat disappointed by. Even though the result of
> the commit had a different hash, I assumed git would keep some kind of
> internal per-commit hash so it could tell later that two commits were
> the same and not re-apply them.

I think there's an important misunderstanding here: merging A into B does *not* have anything to do with commits, or history for that matter, beyond the differences from $(git merge-base A B) to A and B.[*]

Along the same lines, nothing is ever re-applied during merging. git-merge just figures out that you made the same change on both sides, so it must have been a good change, so it must go into the end result. *How* you arrived at the same change---say, by cherry-picking, or by getting the same result in that region from otherwise different commits, or even from several commits---does *not* matter in any way.

You can use 'git cherry', 'git log --left-right --cherry-pick', and similar tools to find commits that are cherry-picked "duplicates", but unless you rewrite history, they are there to stay.

[*] This is a simplification since as soon as the merge-base is not unique, merge-recursive will actually start looking into history further back.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch