Thank you Jeff for your elaboration! The algorithm is now clear to me and I can see why the log has been empty.
However, I don't think the default simplification algorithm is a good default when used in combination with "--merges". "git log --merges file" looks very natural if I want to answer the question "When has file been merged into my master/develop/whatsoever branch?" and it just doesn't work. Is there a simpler way to answer that question? What is the primary use of "--merges" if not combined with "--full-history" or at least "--first-parent"? I would only see merges where file has been a "merge conflict". What do you think about implying "--full-history" when using "--merges"? Best regards, Dominik > > (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
