{"thread":{"id":"40030","subject":"Inconsistent results obtained regarding how git decides what commits modifies a given path","startedAt":"2015-08-07T06:42:52Z","lastAt":"2015-08-07T08:44:26Z","messageCount":2,"participants":["JuanLeon Lahoz","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"267605","messageId":"CANYPdHA6a1Jg2NUJGcg5O3KBG2AB+AK3071ckDywGL=MHghEZA@mail.gmail.com","threadId":"40030","inReplyTo":null,"subject":"Inconsistent results obtained regarding how git decides what commits modifies a given path","fromName":"JuanLeon Lahoz","fromEmail":"juanleon.lahoz@gmail.com","sentAt":"2015-08-07T06:42:52Z","receivedAt":"2015-08-07T06:42:52Z","isPatch":false,"sender":{"key":"juanleon.lahoz@gmail.com","avatar":null},"body":"When I use git rev-list (or git log) with the -- option to restrict commits to\nthose that modify a path, I am getting resuls where I fail to see the\nconsistency. Worse than that, results vary with git version (pre 1.8.4, results\nwere consistent; in 1.8.4 or 2.5.0 they don't seem consistent to me, and they\nare different than in older versions; I rather like more the pre 1.8.4\nbehaviour).\n\nInconsistencies (inside same git version) or differences (across versions)\naffects only to merge commits that affect (depending on definition) to a file.\n\nAs per manual, \"Commits are included if they are not TREESAME to any parent\",\nbut I think I am getting false positives with git versions >= 1.8.4.\n\nHere is an example where I find the results that confuse me:\n\n-------------------------------------------\n\n#!/bin/bash -e\ngit init\ngit commit --allow-empty -m initial\n\n# Create four branches, each one enclosing the previous one\necho v1 > version\ngit add version\ngit commit -m v1\ngit branch b1\n\necho v2 > version\ngit add version\ngit commit -m v2\ngit branch b2\n\necho v3 > version\ngit add version\ngit commit -m v3\ngit branch b3\n\necho v4 > version\ngit add version\ngit commit -m v4\ngit branch b4\n\ngit tag checkpoint\n# We create a couple of merges\ngit checkout -b b2_3 b2\ngit merge --no-ff b3\n\ngit checkout -b b1_4 b1\ngit merge --no-ff b4\n\n# This prints nothing on git < 1.8.4; prints a commit that corresponds with\n# \"Merge branch 'b3' into b2_3\" in git >= 1.8.4 (tested with 1.8.4 and 2.5.0)\necho COMMITS checkpoint..b2_3: $(git rev-list checkpoint..b2_3 -- version)\n# This prints nothing on any git version I tested.\necho COMMITS checkpoint..b1_4: $(git rev-list checkpoint..b1_4 -- version)\n\n-------------------------------------------\n\nIs that a bug or I am misunderstanding something basic?\n\nThanks\njuanleon\n"},{"id":"267606","messageId":"20150807084425.GA8232@sigill.intra.peff.net","threadId":"40030","inReplyTo":"CANYPdHA6a1Jg2NUJGcg5O3KBG2AB+AK3071ckDywGL=MHghEZA@mail.gmail.com","subject":"Re: Inconsistent results obtained regarding how git decides what commits modifies a given path","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-08-07T08:44:26Z","receivedAt":"2015-08-07T08:44:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 07, 2015 at 08:42:52AM +0200, JuanLeon Lahoz wrote:\n\n> # This prints nothing on git < 1.8.4; prints a commit that corresponds with\n> # \"Merge branch 'b3' into b2_3\" in git >= 1.8.4 (tested with 1.8.4 and 2.5.0)\n> echo COMMITS checkpoint..b2_3: $(git rev-list checkpoint..b2_3 -- version)\n\nI would expect the current behavior (to show the merge). The fix bisects\nto d0af663 (revision.c: Make --full-history consider more merges,\n2013-05-16). See that commit message, or the thread at:\n\n  http://thread.gmane.org/gmane.comp.version-control.git/220624\n\nfor more detail. Though I'm not 100% it was intentional...\n\n> # This prints nothing on any git version I tested.\n> echo COMMITS checkpoint..b1_4: $(git rev-list checkpoint..b1_4 -- version)\n\nThis looks like a bug to me. It should be the exact same simplification\ncase as b2_3 (we have a merge whose outcome matches the second parent,\nbut not the first). One obvious difference, if you look at:\n\n  git log --oneline --graph --decorate checkpoint b2_3 b1_4\n\nis that in the b1_4 case, the immediate parent of the merge is marked as\nUNINTERESTING|BOTTOM, because it is \"checkpoint\". Whereas in the b2_3\ncase, it is simply UNINTERESTING, as it is the _parent_ of checkpoint,\nand we propagated the flag.\n\nThis difference matters in relevant_commit(). In the b2_3 case, we\nconsider the second parent irrelevant, because it is \"just\"\nUNINTERESTING. But in the b1_4 case, we consider it relevant, due to the\nBOTTOM flag. This code comes from 4d82660 (revision.c: discount side\nbranches when computing TREESAME, 2013-05-16).\n\nAnd that commit claims that we exclude irrelevant parents when\ndetermining TREESAME. Meaning the b2_3 case has only one relevant parent\n(which is different, making the merge !TREESAME). Whereas b1_4 has two\nrelevant parents, we realize we are TREESAME to the second one, and\nsimplify away the merge.\n\nAt this point, I'm pretty confused (and reading the comments added by\n4282660 only confused me further). I would have thought the TREESAME was\nindependent of the limiting of the traversal, but clearly it is not\nintended to be. But this weird BOTTOM exception makes even less sense to\nme.\n\nSo I'll give up for now. Maybe somebody else can pick it up from there,\nor perhaps it will make more sense to me in the morning.\n\n-Peff\n"}]}