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

[Thomas Rast <trast@student.ethz.ch>]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

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



[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]