skillzero@xxxxxxxxx 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:
signature.asc
Description: This is a digitally signed message part.
