{"thread":{"id":"40793","subject":"git log --merges doesn't show commits as expected","startedAt":"2015-11-13T16:21:36Z","lastAt":"2015-11-13T22:35:23Z","messageCount":2,"participants":["Dominik Rauch","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"273283","messageId":"AMSPR02MB168531F809E1625FACEB25283110@AMSPR02MB168.eurprd02.prod.outlook.com","threadId":"40793","inReplyTo":null,"subject":"git log --merges doesn't show commits as expected","fromName":"Dominik Rauch","fromEmail":"dominik.rauch@gmx.at","sentAt":"2015-11-13T16:21:36Z","receivedAt":"2015-11-13T16:21:36Z","isPatch":false,"sender":{"key":"dominik.rauch@gmx.at","avatar":null},"body":"Hello!\n \n(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.)\n\nI have the following repository tree:\n\nC\n|\\\n| B\n| /\nA\n\nCommit A: Parents=(). Initial commit. Contains file foo with content \"ABC\".\nCommit B: Parents=(A). Represents a commit on some feature branch. Contains file foo with content \"XYZ\".\nCommit C: Parents=(A, B). Represents a merge commit of a feature branch back to the main branch. Contains file foo with content \"XYZ\".\n\nI 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...).\n\nDoes anybody know why I don't see the log output I expect? I'm confused...even if the log output is correct, I don't think it follows the principle of least surprise...\n\nSide note: specifying \"--first-parent\" also results in commit C being shown.\n\nBest regards,\nDominik\n\nPS: This is a cross post of [2], somebody noted it could be a bug, which is why I decided to post to this mailing list.\n\n[1] https://git-scm.com/docs/git-log#_history_simplification \n[2] http://stackoverflow.com/q/33695763/\n"},{"id":"273294","messageId":"20151113223523.GB14830@sigill.intra.peff.net","threadId":"40793","inReplyTo":"AMSPR02MB168531F809E1625FACEB25283110@AMSPR02MB168.eurprd02.prod.outlook.com","subject":"Re: git log --merges doesn't show commits as expected","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-11-13T22:35:23Z","receivedAt":"2015-11-13T22:35:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 13, 2015 at 04:21:36PM +0000, Dominik Rauch wrote:\n\n> (This is my first post to this mailing list and I couldn't find a FAQ\n> section - please excuse me, if I haven't followed all the established\n> posting guidelines yet.)\n\nThis is the right place. Welcome. :)\n\n> I have the following repository tree:\n> \n> C\n> |\\\n> | B\n> | /\n> A\n> \n> Commit A: Parents=(). Initial commit. Contains file foo with content \"ABC\".\n> Commit B: Parents=(A). Represents a commit on some feature branch. Contains file foo with content \"XYZ\".\n> Commit C: Parents=(A, B). Represents a merge commit of a feature branch back to the main branch. Contains file foo with content \"XYZ\".\n> \n> I expected \"git log --merges foo\" to show C, however, the log is\n> empty! Specifying \"--full-history\" results in the correct history,\n> therefore I assume, I misunderstand Git's default history\n> simplification algorithm. Unfortunately, the example in the Git docs\n> at [1] does not contain the very same situation (although it is\n> probably one of the most common situations...).\n\nI don't think \"--merges\" is relevant to the simplification here. By\nasking for \"foo\", that turns on history simplification. Since the merge\nat C took one side directly, that means we can cull the parent link that\nleads to A (its foo=ABC did not contribute to the final outcome). And\nthen C is TREESAME to its only remaining parent (they both have\nfoo=XYZ), so it can be removed, leaving only commit B to be passed to\nthe next stage.\n\nAnd then we apply \"--merges\", and see that B is not a merge, and so\ndo not show it (but we still traverse it, of course).\n\nIn theory we could apply \"--merges\" first (by simplifying history to\nshrink any chains of non-merges to a single point). But I don't think\nthere's any way to do that currently with git.\n\n-Peff\n"}]}