On Fri, Nov 13, 2015 at 04:21:36PM +0000, Dominik Rauch wrote: > (This is my first post to this mailing list and I couldn't find a FAQ > section - please excuse me, if I haven't followed all the established > posting guidelines yet.) This is the right place. Welcome. :) > I have the following repository tree: > > C > |\ > | B > | / > A > > Commit A: Parents=(). Initial commit. Contains file foo with content "ABC". > Commit B: Parents=(A). Represents a commit on some feature branch. Contains file foo with content "XYZ". > Commit C: Parents=(A, B). Represents a merge commit of a feature branch back to the main branch. Contains file foo with content "XYZ". > > I expected "git log --merges foo" to show C, however, the log is > empty! Specifying "--full-history" results in the correct history, > therefore I assume, I misunderstand Git's default history > simplification algorithm. Unfortunately, the example in the Git docs > at [1] does not contain the very same situation (although it is > probably one of the most common situations...). I don't think "--merges" is relevant to the simplification here. By asking for "foo", that turns on history simplification. Since the merge at C took one side directly, that means we can cull the parent link that leads to A (its foo=ABC did not contribute to the final outcome). And then C is TREESAME to its only remaining parent (they both have foo=XYZ), so it can be removed, leaving only commit B to be passed to the next stage. And then we apply "--merges", and see that B is not a merge, and so do not show it (but we still traverse it, of course). In theory we could apply "--merges" first (by simplifying history to shrink any chains of non-merges to a single point). But I don't think there's any way to do that currently with git. -Peff -- 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