On 7 July 2015 at 01:48, Peter Stuge <pe...@stuge.se> wrote: > fact that a merge commit ideally does *not* contain any > modifications.
That's not /entirely/ true. The merge commit will have a new TREE object which is a composite TREE object of both of its PARENT TREE objects ( But all BLOBs in the resulting TREE will have existed on one of the parents as-is ) But as I mentioned in another reply, there's no way to view only the treewise diffs in a format suitable for diff, because diffs pertain to file contents, not SHA1s of BLOBs and SHA1s of TREEs. And yes, "Ideally" is where it gets messy. Non-Ideal commits have *new* BLOB objects that don't exist on either parent, and these can be hard to deal with. There's additionally lots of git tools that use the merge infrastructure to create non-merge commits with multiple parents. ( Git subtree for instance ), and some of them may inject *files* into the tree that don't exist in either parent, or entirely re-order the structure of one of the parents before applying it to master. The problem with those "merge" commits is those commits contain a significant amount of state in the merge itself, such that you cannot trivially recreate the merge commit from either of its parents alone. You can additionally turn any existing commit into one with two parents without changing the commits own changes, simply by abusing the model and git grafts and telling git "This commit now has two parents". Git goes "Sure, I'll put that SHA1 there and make no other changes". -- Kent KENTNL - https://metacpan.org/author/KENTNL
