2009/1/14 Thomas Rast <trast@xxxxxxxxxxxxxxx>: > skillzero@xxxxxxxxx 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. Yes, merge only considers what bytes (aka contents of trees-directories and blobs-files) do the branches to be merged have, compares them (by comparing their hashes) and if there are differences tries to mix them together according to the merge rules described somewhere in Documentation. So this all is really just about what the branches contain, not how they got it. It is the conflict resolution algorithm which uses the history to find the best possible source blob or tree which was changed by conflicting branches so the "mix" can be prepared as close as possible to what would we do if we went looking for the pieces manually. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
