{"thread":{"id":"56849","subject":"List all commits of a specified file in oldest to newest order","startedAt":"2021-11-05T04:18:13Z","lastAt":"2021-12-14T03:58:52Z","messageCount":9,"participants":["Vipul Kumar","Jeff King","Ævar Arnfjörð Bjarmason","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"440500","messageId":"c3932b3c-323a-39d6-26a7-ba0c3d17378b@onenetbeyond.org","threadId":"56849","inReplyTo":null,"subject":"List all commits of a specified file in oldest to newest order","fromName":"Vipul Kumar","fromEmail":"kumar+git@onenetbeyond.org","sentAt":"2021-11-05T04:10:31Z","receivedAt":"2021-11-05T04:18:13Z","isPatch":false,"sender":{"key":"kumar+git@onenetbeyond.org","avatar":null},"body":"Hi,\n\nI want to list all commits (including renames) of a specified file in \noldest to newest order. But when I run \"git log --follow --reverse -- \n<path/to/the/file>\" command, I'm getting a single commit, which points \nto the \"rename of the file\". This behavior is weird to me because I \nexpected to get list of all commit in oldest to newest order, whereas \n\"git log --follow -- <path/to/the/file>\" command works as expected.\n\n### Steps to reproduce\n\n$ git init test\n$ cd test\n$ echo \"Hello from foo.\" > a.txt\n$ git add a.txt\n$ git commit -m 'Initial commit'\n$ git mv a.txt b.txt\n$ git commit -m 'Rename a.txt to b.txt'\n$ git log --follow -- b.txt\ncommit 55e3e6857755fe815449e787a90fe82feb174817\nAuthor: Redacted <Redacted>\nDate:   Fri Nov 5 06:56:58 2021 +0530\n\n     Rename a.txt to b.txt\n\ncommit f40baf5e777b2618e02805d16c950687d98356fe\nAuthor: Redacted <Redacted>\nDate:   Fri Nov 5 06:53:35 2021 +0530\n\n     Initial commit\n$ git log --follow --reverse -- b.txt\ncommit 55e3e6857755fe815449e787a90fe82feb174817\nAuthor: Redacted <Redacted>\nDate:   Fri Nov 5 06:56:58 2021 +0530\n\n     Rename a.txt to b.txt\n\n\n### Expected output\n\nAs far as I understand, using \"--reverse\" option along with \"git log\" \ncommand reverse the chronological order of the commits. So expected \noutput of \"git log --follow --reverse\" command should be in oldest to \nnewest commits order that's reverse the chronological order of \"git log \n--follow\" command's output.\n\n$ git log --follow --reverse -- b.txt\ncommit f40baf5e777b2618e02805d16c950687d98356fe\nAuthor: Redacted <Redacted>\nDate:   Fri Nov 5 06:53:35 2021 +0530\n\n     Initial commit\n\ncommit 55e3e6857755fe815449e787a90fe82feb174817\nAuthor: Redacted <Redacted>\nDate:   Fri Nov 5 06:56:58 2021 +0530\n\n     Rename a.txt to b.txt\n\n\n### Actual output\n\nBut when I use \"--reverse\" along with \"--follow\" option, I'm getting a \nsingle commit which points to the rename of the file.\n\n$ git log --follow --reverse -- b.txt\ncommit 55e3e6857755fe815449e787a90fe82feb174817\nAuthor: Redacted <Redacted>\nDate:   Fri Nov 5 06:56:58 2021 +0530\n\n     Rename a.txt to b.txt\n\n\n### Additional\n\n$ git --version\ngit version 2.33.0\n\nFirst I thought \"--follow --reverse\" showing to me the newest commit. \nBut later, I found out that, it always shows a single commit which \npoints to the rename of the file.\n\n$ echo \"Hello from bar.\" >> b.txt\n$ git add b.txt\n$ git commit -m 'Update b.txt'\n$ git log --follow --reverse -- b.txt\ncommit 55e3e6857755fe815449e787a90fe82feb174817\nAuthor: Redacted <Redacted>\nDate:   Fri Nov 5 06:56:58 2021 +0530\n\n     Rename a.txt to b.txt\n\n\n\nCheers,\nVipul\n"},{"id":"440509","messageId":"YYTorS1DiuTXv0/V@coredump.intra.peff.net","threadId":"56849","inReplyTo":"c3932b3c-323a-39d6-26a7-ba0c3d17378b@onenetbeyond.org","subject":"Re: List all commits of a specified file in oldest to newest order","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-11-05T08:17:49Z","receivedAt":"2021-11-05T08:17:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 05, 2021 at 04:10:31AM +0000, Vipul Kumar wrote:\n\n> I want to list all commits (including renames) of a specified file in oldest\n> to newest order. But when I run \"git log --follow --reverse --\n> <path/to/the/file>\" command, I'm getting a single commit, which points to\n> the \"rename of the file\". This behavior is weird to me because I expected to\n> get list of all commit in oldest to newest order, whereas \"git log --follow\n> -- <path/to/the/file>\" command works as expected.\n\nThis has to do with the hacky way --follow is implemented. We don't\ncompute the full set of commits to show ahead of time, but rather as we\ntraverse, we change which pathspec we'll match when we hit a commit that\nhas a rename. Whereas --reverse is applied before we even start the main\ntraversal, and instead collect all possible commits and then walk them\nin reverse order.\n\nSo the very first commit we'll look at for --follow is the one that\ncreated the file from the rename, at which point we'll start looking\nonly for the old name. But of course all of the other commits post-date\nthe rename, so they don't use that old name.\n\nSo yes, it's a bug in the sense that the behavior is nonsense and it\ndoesn't work as one might expect. But it's also the hacky \"--follow\"\nworking as designed, and is just a limitation of its approach. It would\nneed to be rewritten completely to work correctly.  Arguably we should\nat least disallow the combination of --reverse and --follow for now, as\nit will never help (OTOH, if there is nothing to follow it should behave\nOK, and I suspect some people and scripts may add --follow \"just in\ncase\").\n\nAs a workaround, you can get what you want by two separate traversals:\none to collect the commits via --follow, and then another to actually\nshow them (but without doing any further walking). Like:\n\n  git log --follow --format=%H -- $your_file |\n  git log --stdin --no-walk --reverse [--oneline, -p, etc]\n\n-Peff\n"},{"id":"440510","messageId":"211105.86a6ijhujg.gmgdl@evledraar.gmail.com","threadId":"56849","inReplyTo":"c3932b3c-323a-39d6-26a7-ba0c3d17378b@onenetbeyond.org","subject":"Re: List all commits of a specified file in oldest to newest order","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-11-05T08:13:54Z","receivedAt":"2021-11-05T08:32:45Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Nov 05 2021, Vipul Kumar wrote:\n\n> I want to list all commits (including renames) of a specified file in\n> oldest to newest order. But when I run \"git log --follow --reverse -- \n> <path/to/the/file>\" command, I'm getting a single commit, which points\n> to the \"rename of the file\". This behavior is weird to me because I \n> expected to get list of all commit in oldest to newest order, whereas\n> \"git log --follow -- <path/to/the/file>\" command works as expected.\n\nThis is a known caveat of how the history traversal works, but from a\nquick glance I couldn't see any explicit documentation for it, aside\nfrom this terse mention in git-log(1):\n\n     \"[-M can be used] for following files across renames while\n     traversing history, see --follow.\".\n\nThe key thing being the \"traversal\", i.e. as we walk history we'll\nencounter a tree entry where b.txt was deleted, and see that it was\nmoved from a.txt.\n\nHowever, if we walk history from the beginning we have no idea of the\nrelationship of a->b.txt, since we didn't encounter that commit yet,\nthat's only something we see while walking the history.\n\nPerhaps we should have some option like --buffer-then-reverse, which\nwouldn't change the walking order, but would only change the output, but\nwe don't.\n\nThis caveat doesn't only apply to reverse, try to apply a move of b.txt\non top of your history:\n\n    b.txt -> c.txt\n\nAnd now do:\n\n    git log [--follow] -- b.txt\n\nWhat should we output there? If we're arguing that we should first\ntraverse the history to \"look forward\" that'll also apply to a\nnon-reverse walk, since we're asking to follow b.txt.\n\nBut we haven't encountered the b->c.txt relationship yet (well, we run\ninto the rename commit, but once you add a c->d.txt on top...). So maybe\ninstead of --buffer-then-reverse we'd need a hypothetical --two-pass,\nwhich would also impact options other than --reverse whose behavior\nrelies on traversal order.\n\nTake all the above as an explanation for how it works now, not some\ndefense of this being user-friendly. I've also often been annoyed at\nthis behavior.\n\nFor small sets you can feed your into an alias like:\n\n    git show $(git -P log --pretty=format:\"%h\" --pretty=tformat:%H --follow -- b.txt | tac)\n\nAs a poor man's --buffer-then-reverse.\n"},{"id":"440541","messageId":"xmqq7ddmxwtc.fsf@gitster.g","threadId":"56849","inReplyTo":"YYTorS1DiuTXv0/V@coredump.intra.peff.net","subject":"Re: List all commits of a specified file in oldest to newest order","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-11-05T18:49:03Z","receivedAt":"2021-11-05T18:49:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> As a workaround, you can get what you want by two separate traversals:\n> one to collect the commits via --follow, and then another to actually\n> show them (but without doing any further walking). Like:\n>\n>   git log --follow --format=%H -- $your_file |\n>   git log --stdin --no-walk --reverse [--oneline, -p, etc]\n\nWe learn new things every day.\n\nKnowing the implementation, it is sort of obvious (we push the\nobjects into the pending list, populate the revs.commits in\nprepare_revision_walk() from the pending list in order,\nget_revision() first reverses the revs.commits and then gives out\nthe elements), but I didn't know the combination of \"--no-walk\" and\n\"--reverse\" did something sensible ;-)\n\nThanks.\n"},{"id":"440559","messageId":"YYW9mfsyemUsBezG@coredump.intra.peff.net","threadId":"56849","inReplyTo":"xmqq7ddmxwtc.fsf@gitster.g","subject":"Re: List all commits of a specified file in oldest to newest order","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-11-05T23:26:17Z","receivedAt":"2021-11-05T23:26:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 05, 2021 at 11:49:03AM -0700, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > As a workaround, you can get what you want by two separate traversals:\n> > one to collect the commits via --follow, and then another to actually\n> > show them (but without doing any further walking). Like:\n> >\n> >   git log --follow --format=%H -- $your_file |\n> >   git log --stdin --no-walk --reverse [--oneline, -p, etc]\n> \n> We learn new things every day.\n> \n> Knowing the implementation, it is sort of obvious (we push the\n> objects into the pending list, populate the revs.commits in\n> prepare_revision_walk() from the pending list in order,\n> get_revision() first reverses the revs.commits and then gives out\n> the elements), but I didn't know the combination of \"--no-walk\" and\n> \"--reverse\" did something sensible ;-)\n\nI admit that I did not know if it would work either until I tried it\nearlier today. ;)\n\n-Peff\n"},{"id":"440729","messageId":"182017f6-5dcd-70f0-e0bc-98721c433bf3@onenetbeyond.org","threadId":"56849","inReplyTo":"211105.86a6ijhujg.gmgdl@evledraar.gmail.com","subject":"Re: List all commits of a specified file in oldest to newest order","fromName":"Vipul Kumar","fromEmail":"kumar@onenetbeyond.org","sentAt":"2021-11-09T03:35:51Z","receivedAt":"2021-11-09T03:43:34Z","isPatch":false,"sender":{"key":"kumar@onenetbeyond.org","avatar":"https://avatars.githubusercontent.com/u/28824347?v=4"},"body":"On 11/5/21 8:13 AM, Ævar Arnfjörð Bjarmason wrote:\n> \n> The key thing being the \"traversal\", i.e. as we walk history we'll\n> encounter a tree entry where b.txt was deleted, and see that it was\n> moved from a.txt.\n\nThanks, I didn't know \"reverse\" would change the traversal order. When I \nlooked for \"--reverse\" option in git-log(1), this what I found:\n\n   --reverse\n       Output the commits chosen to be shown (see Commit Limiting \nsection above) in reverse order. Cannot be combined with --walk-reflogs.\n\n From this, I inferred that \"--follow\" would choose the commits and \n\"--reverse\" reverses those commits order. Can we improve the wording \nhere? Especially, about \"reverse\" changes the traversing order.\n\n> However, if we walk history from the beginning we have no idea of the\n> relationship of a->b.txt, since we didn't encounter that commit yet,\n> that's only something we see while walking the history.\n\nNot showing commits before rename is expected, but I didn't understand \nwhy combination \"--follow\" and \"--reverse\" option showing me only one \ncommit? And it always points to the rename of the file. Shouldn't it \nalso list other commits which changes that file? For example, just after \n\"rename of a.txt to b.txt\", do some changes in b.txt file and then run \n\"git log --follow --reverse -- b.txt\" command.\n\n$ for i in {1..2}; do echo \"$i\" >> b.txt; git add b.txt; git commit -m \n\"Update$i b.txt\"; done\n$ git log --follow --reverse -- b.txt\ncommit 55e3e6857755fe815449e787a90fe82feb174817\nAuthor: Redacted <Redacted>\nDate:   Fri Nov 5 06:56:58 2021 +0530\n\n     Rename a.txt to b.txt\n\nHere I expect output to be:\n\n$ git log --follow --reverse -- b.txt\ncommit 55e3e6857755fe815449e787a90fe82feb174817\nAuthor: Reacted <Redacted>\nDate:   Fri Nov 5 06:56:58 2021 +0530\n\n     Rename a.txt to b.txt\n\ncommit 57aac6d1af2d869557991e714932847f37035d19\nAuthor: Redacted <Redacted>\nDate:   Sun Nov 7 20:30:32 2021 +0530\n\n     Update1 b.txt\n\ncommit ea76a8e8af903dc1522626aa058b8058afbe11f4\nAuthor: Redacted <Redacted>\nDate:   Sun Nov 7 20:30:32 2021 +0530\n\n     Update2 b.txt\n\nI know, here using \"--follow\" along with \"--reverse\" doesn't make any \nsense. Instead we should use \"git log --reverse -- b.txt\". But I'm just \ncurious, is this also an expected caveats of using \"--follow\" along with \n\"--reverse\"?\n\n> This caveat doesn't only apply to reverse, try to apply a move of b.txt\n> on top of your history:\n> \n>      b.txt -> c.txt\n> \n> And now do:\n> \n>      git log [--follow] -- b.txt\n> \n> What should we output there? If we're arguing that we should first\n> traverse the history to \"look forward\" that'll also apply to a\n> non-reverse walk, since we're asking to follow b.txt.\n> \n> But we haven't encountered the b->c.txt relationship yet (well, we run\n> into the rename commit, but once you add a c->d.txt on top...). So maybe\n> instead of --buffer-then-reverse we'd need a hypothetical --two-pass,\n> which would also impact options other than --reverse whose behavior\n> relies on traversal order.\n\n\"--two-pass\" option sounds like a good idea, but not sure how useful it \nwould be for others. In my case, I could read the log's command output \nin bottom to top fashion, and now I also know two other approaches to \nget what I wanted. And I usually don't track deleted file.\n\n\n-v\n"},{"id":"440731","messageId":"6c6ef97c-9de5-176f-f328-c4dffd96d495@onenetbeyond.org","threadId":"56849","inReplyTo":"YYTorS1DiuTXv0/V@coredump.intra.peff.net","subject":"Re: List all commits of a specified file in oldest to newest order","fromName":"Vipul Kumar","fromEmail":"kumar@onenetbeyond.org","sentAt":"2021-11-09T05:24:50Z","receivedAt":"2021-11-09T05:34:34Z","isPatch":false,"sender":{"key":"kumar@onenetbeyond.org","avatar":"https://avatars.githubusercontent.com/u/28824347?v=4"},"body":"On 11/5/21 8:17 AM, Jeff King wrote:\n\n> So yes, it's a bug in the sense that the behavior is nonsense and it\n> doesn't work as one might expect. But it's also the hacky \"--follow\"\n> working as designed, and is just a limitation of its approach. It would\n> need to be rewritten completely to work correctly.  Arguably we should\n> at least disallow the combination of --reverse and --follow for now, as\n> it will never help (OTOH, if there is nothing to follow it should behave\n> OK, and I suspect some people and scripts may add --follow \"just in\n> case\").\n\nI think, it's a good idea to disallow the combination of \"--reverse\" and \n\"--follow\", just like we did for \"--reverse\" and \"--walk-reflogs\" \ncombination. Because this combination never going to help anybody:\n\n   * If there is nothing to follow, people shouldn't use \"--follow\" \noption. Using \"--follow\" along with \"--reverse\" might arise \nmisconception to users that they are also following renames also, which \nactually they don't.\n\n   * But if there are things to follow, using combination of \"--follow\" \nand \"--reverse\" only shows a single commit which points to the \"rename \nof the file\". I quite didn't understand why is this happening? Once we \nencounter rename commit (from \"a.txt to b.txt\") while traversing in \nreverse order, our pathspec is now \"b.txt\". So we should also get list \nof commits which changes b.txt file.\n\n> As a workaround, you can get what you want by two separate traversals:\n> \n>    git log --follow --format=%H -- $your_file |\n>    git log --stdin --no-walk --reverse [--oneline, -p, etc]\n\nThank you!\n\n\n-v\n"},{"id":"440734","messageId":"211109.864k8lvesb.gmgdl@evledraar.gmail.com","threadId":"56849","inReplyTo":"182017f6-5dcd-70f0-e0bc-98721c433bf3@onenetbeyond.org","subject":"Re: List all commits of a specified file in oldest to newest order","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-11-09T09:42:27Z","receivedAt":"2021-11-09T09:50:43Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Nov 09 2021, Vipul Kumar wrote:\n\n> On 11/5/21 8:13 AM, Ævar Arnfjörð Bjarmason wrote:\n>> The key thing being the \"traversal\", i.e. as we walk history we'll\n>> encounter a tree entry where b.txt was deleted, and see that it was\n>> moved from a.txt.\n>\n> Thanks, I didn't know \"reverse\" would change the traversal order. When\n> I looked for \"--reverse\" option in git-log(1), this what I found:\n>\n>   --reverse\n>       Output the commits chosen to be shown (see Commit Limiting\n>       section above) in reverse order. Cannot be combined with\n>      --walk-reflogs.\n>\n> From this, I inferred that \"--follow\" would choose the commits and\n> \"--reverse\" reverses those commits order. Can we improve the wording \n> here? Especially, about \"reverse\" changes the traversing order.\n\nYes, definitely. Suggestions most welcome :)\n\n>> However, if we walk history from the beginning we have no idea of the\n>> relationship of a->b.txt, since we didn't encounter that commit yet,\n>> that's only something we see while walking the history.\n>\n> Not showing commits before rename is expected, but I didn't understand\n> why combination \"--follow\" and \"--reverse\" option showing me only one \n> commit? And it always points to the rename of the file. Shouldn't it\n> also list other commits which changes that file? For example, just\n> after \"rename of a.txt to b.txt\", do some changes in b.txt file and\n> then run \"git log --follow --reverse -- b.txt\" command.\n>\n> $ for i in {1..2}; do echo \"$i\" >> b.txt; git add b.txt; git commit -m\n> \"Update$i b.txt\"; done\n> $ git log --follow --reverse -- b.txt\n> commit 55e3e6857755fe815449e787a90fe82feb174817\n> Author: Redacted <Redacted>\n> Date:   Fri Nov 5 06:56:58 2021 +0530\n>\n>     Rename a.txt to b.txt\n>\n> Here I expect output to be:\n>\n> $ git log --follow --reverse -- b.txt\n> commit 55e3e6857755fe815449e787a90fe82feb174817\n> Author: Reacted <Redacted>\n> Date:   Fri Nov 5 06:56:58 2021 +0530\n>\n>     Rename a.txt to b.txt\n>\n> commit 57aac6d1af2d869557991e714932847f37035d19\n> Author: Redacted <Redacted>\n> Date:   Sun Nov 7 20:30:32 2021 +0530\n>\n>     Update1 b.txt\n>\n> commit ea76a8e8af903dc1522626aa058b8058afbe11f4\n> Author: Redacted <Redacted>\n> Date:   Sun Nov 7 20:30:32 2021 +0530\n>\n>     Update2 b.txt\n>\n> I know, here using \"--follow\" along with \"--reverse\" doesn't make any\n> sense. Instead we should use \"git log --reverse -- b.txt\". But I'm\n> just curious, is this also an expected caveats of using \"--follow\"\n> along with \"--reverse\"?\n\nI just assumed this would work, but looking a bit closer it doesn't\nreally, a better test-case:\n    \n    (   \n        rm -rf /tmp/gt &&\n        git init /tmp/gt &&\n        cd /tmp/gt &&\n        echo hi >a.txt &&\n        git add a.txt &&\n        git commit -m\"initial\" &&\n        for i in {b..z}\n        do\n            git mv * $i.txt &&\n            git commit -m\"Moved to $i.txt\"\n        done\n    )\n\nAnd if you want to dig the ad-hoc fprintf debugging below is probably a\ngood start.\n\nI.e. I think we should do this in principle, but I think we trip over\nourselves in the commit parent discovery, i.e. we should probably fake\nup the \"parent\" as the next commit for the purposes of the traversal &\nfilter options.\n    \n>> This caveat doesn't only apply to reverse, try to apply a move of b.txt\n>> on top of your history:\n>>      b.txt -> c.txt\n>> And now do:\n>>      git log [--follow] -- b.txt\n>> What should we output there? If we're arguing that we should first\n>> traverse the history to \"look forward\" that'll also apply to a\n>> non-reverse walk, since we're asking to follow b.txt.\n>> But we haven't encountered the b->c.txt relationship yet (well, we\n>> run\n>> into the rename commit, but once you add a c->d.txt on top...). So maybe\n>> instead of --buffer-then-reverse we'd need a hypothetical --two-pass,\n>> which would also impact options other than --reverse whose behavior\n>> relies on traversal order.\n>\n> \"--two-pass\" option sounds like a good idea, but not sure how useful\n> it would be for others. In my case, I could read the log's command\n> output in bottom to top fashion, and now I also know two other\n> approaches to get what I wanted. And I usually don't track deleted\n> file.\n\nI think it would be useful to be able to do \"I know this file was\nrenamed to i.txt at some point, what happened after that?\" If we start\nat the tip we'll always traverse all the way to the root.\n\n\ndiff --git a/log-tree.c b/log-tree.c\nindex 644893fd8cf..b3894c995bd 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -960,6 +960,8 @@ static int log_tree_diff(struct rev_info *opt, struct commit *commit, struct log\n \n \t\t/* Set up the log info for the next parent, if any.. */\n \t\tparents = parents->next;\n+\t\tfprintf(stderr, \"log_tree_diff() parent: %s (parents?: %d) (showed_log?: %d)\\n\",\n+\t\t\toid_to_hex(&parent->object.oid), !!parents, showed_log);\n \t\tif (!parents || opt->first_parent_merges)\n \t\t\tbreak;\n \t\tlog->parent = parents->item;\ndiff --git a/tree-diff.c b/tree-diff.c\nindex 437c98a70e4..eeb7af0a516 100644\n--- a/tree-diff.c\n+++ b/tree-diff.c\n@@ -588,6 +588,10 @@ static void try_to_follow_renames(const struct object_id *old_oid,\n \tstruct diff_filepair *choice;\n \tint i;\n \n+\tfprintf(stderr, \"try_to_follow_renames(): %s -> %s\\n\",\n+\t\told_oid ? oid_to_hex(old_oid) : \"NULL\",\n+\t\tnew_oid ? oid_to_hex(new_oid) : \"NULL\");\n+\n \t/*\n \t * follow-rename code is very specific, we need exactly one\n \t * path. Magic that matches more than one path is not\n@@ -633,6 +637,7 @@ static void try_to_follow_renames(const struct object_id *old_oid,\n \t\t * diff_queued_diff, we will also use that as the path in\n \t\t * the future!\n \t\t */\n+\t\tfprintf(stderr, \"%c: for p->one->path = %s...\", p->status, p->one->path);\n \t\tif ((p->status == 'R' || p->status == 'C') &&\n \t\t    !strcmp(p->two->path, opt->pathspec.items[0].match)) {\n \t\t\tconst char *path[2];\n@@ -657,9 +662,11 @@ static void try_to_follow_renames(const struct object_id *old_oid,\n \t\t\t * ourselves; signal diffcore_std() not to muck with\n \t\t\t * rename information.\n \t\t\t */\n+\t\t\tfprintf(stderr, \"found\\n\");\n \t\t\topt->found_follow = 1;\n \t\t\tbreak;\n \t\t}\n+\t\tfprintf(stderr, \"NOT found \\n\");\n \t}\n \n \t/*\n@@ -704,6 +711,10 @@ void diff_tree_oid(const struct object_id *old_oid,\n {\n \tstruct strbuf base;\n \n+\tfprintf(stderr, \"diff_tree_oid() %s -> %s\\n\",\n+\t\told_oid ? oid_to_hex(old_oid) : \"NULL\",\n+\t\tnew_oid ? oid_to_hex(new_oid) : \"NULL\");\n+\n \tstrbuf_init(&base, PATH_MAX);\n \tstrbuf_addstr(&base, base_str);\n \n"},{"id":"444068","messageId":"71d21b15-a5db-dd7e-bc81-06bbef995e31@onenetbeyond.org","threadId":"56849","inReplyTo":"211109.864k8lvesb.gmgdl@evledraar.gmail.com","subject":"Re: List all commits of a specified file in oldest to newest order","fromName":"Vipul Kumar","fromEmail":"kumar@onenetbeyond.org","sentAt":"2021-12-14T03:58:31Z","receivedAt":"2021-12-14T03:58:52Z","isPatch":false,"sender":{"key":"kumar@onenetbeyond.org","avatar":"https://avatars.githubusercontent.com/u/28824347?v=4"},"body":"Hi, sorry for delay reply. I was busy with some other works and couldn't \nfind the time to look into it.\n\nOn 11/9/21 9:42 AM, Ævar Arnfjörð Bjarmason wrote:\n> \n>> Thanks, I didn't know \"reverse\" would change the traversal order. When\n>> I looked for \"--reverse\" option in git-log(1), this what I found:\n>>\n>>    --reverse\n>>        Output the commits chosen to be shown (see Commit Limiting\n>>        section above) in reverse order. Cannot be combined with\n>>       --walk-reflogs.\n>>\n>>  From this, I inferred that \"--follow\" would choose the commits and\n>> \"--reverse\" reverses those commits order. Can we improve the wording\n>> here? Especially, about \"reverse\" changes the traversing order.\n> \n> Yes, definitely. Suggestions most welcome :)\n\n   --reverse\n       Traverse the commits chosen to be shown (see Commit Limiting \nsection above) in reverse order. Cannot be combined with --walk-reflogs.\n\nIf we don't want to disallow combination of \"--follow\" and \"--reverse\", \njust like \"--walk-reflogs\" as combination doesn't make any sense[1]. We \ncould do this:\n\n   --reverse\n       Traverse the commits chosen to be shown (see Commit Limiting \nsection above) in reverse order. Cannot be combined with --walk-reflogs. \nCombination of --follow and --reverse won't produce an expected output, \nif we also want to follow renames. If there is nothing to follow it \nshould behave as expected.\n\n[1]: \nhttps://public-inbox.org/git/6c6ef97c-9de5-176f-f328-c4dffd96d495@onenetbeyond.org/\n\nDoes it sound good to you?\n\n-v\n"}]}