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

> skillzero@gmail.com wrote:
>> 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.