{"thread":{"id":"40796","subject":"Re: Re: git log --merges doesn't show commits as expected","startedAt":"2015-11-13T23:10:44Z","lastAt":"2015-11-13T23:32:39Z","messageCount":2,"participants":["Dominik Rauch","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"273297","messageId":"AMSPR02MB168F9B2126871F4702CBA5483110@AMSPR02MB168.eurprd02.prod.outlook.com","threadId":"40796","inReplyTo":null,"subject":"Re: Re: git log --merges doesn't show commits as expected","fromName":"Dominik Rauch","fromEmail":"dominik.rauch@gmx.at","sentAt":"2015-11-13T23:10:44Z","receivedAt":"2015-11-13T23:10:44Z","isPatch":false,"sender":{"key":"dominik.rauch@gmx.at","avatar":null},"body":"Thank you Jeff for your elaboration! The algorithm is now clear to me and I can see why the log has been empty.\n\nHowever, 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\"?\n\nBest regards,\nDominik\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> \n> This 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> \n> 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.\n> \n> 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).\n> \n> 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.\n> \n> -Peff\n"},{"id":"273300","messageId":"20151113233239.GC16173@sigill.intra.peff.net","threadId":"40796","inReplyTo":"AMSPR02MB168F9B2126871F4702CBA5483110@AMSPR02MB168.eurprd02.prod.outlook.com","subject":"Re: Re: git log --merges doesn't show commits as expected","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-11-13T23:32:39Z","receivedAt":"2015-11-13T23:32:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 13, 2015 at 11:10:44PM +0000, Dominik Rauch wrote:\n\n> However, I don't think the default simplification algorithm is a good\n> default when used in combination with \"--merges\". \"git log --merges\n> file\" looks very natural if I want to answer the question \"When has\n> file been merged into my master/develop/whatsoever branch?\" and it\n> just doesn't work. Is there a simpler way to answer that question?\n\nI would generally use --first-parent to just walk down the commits that\nfirst-appeared on the master branch. You don't really need --merges\nthen; you see all direct changes on the branch, and if you have a topic\nbranch workflow, you'll essentially only see merges anyway.\n\n> What is the primary use of \"--merges\" if not combined with\n> \"--full-history\" or at least \"--first-parent\"?\n\nUsing \"--merges\" is orthogonal to --full-history. You might not even be\nsimplifying history at all (the reason we do simplification in your\nexample is because of the \"foo\" pathspec you provide).\n\nI don't use --merges by itself very much (I use --no-merges much more\noften).\n\n> What do you think about implying \"--full-history\" when using \"--merges\"?\n\nI haven't thought hard about it, but my first instinct is that we should\nnot. Even if they are _mostly_ used together, they are orthogonal\nconcepts, and we'd be breaking backwards compatibility.\n\n-Peff\n"}]}