{"thread":{"id":"23804","subject":"Git log follow question","startedAt":"2010-05-14T00:57:34Z","lastAt":"2010-05-26T14:40:22Z","messageCount":12,"participants":["Albert Krawczyk","Bo Yang","Jeff King","Linus Torvalds","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"141621","messageId":"006d01caf300$703e96a0$50bbc3e0$@burgmann.anu.edu.au","threadId":"23804","inReplyTo":null,"subject":"Git log follow question","fromName":"Albert Krawczyk","fromEmail":"albert@burgmann.anu.edu.au","sentAt":"2010-05-14T00:57:34Z","receivedAt":"2010-05-14T00:57:34Z","isPatch":false,"sender":{"key":"albert@burgmann.anu.edu.au","avatar":null},"body":"Hi Everybody,\n\nI'm having an issue understanding the way git log --follow works with git\nlog --parents\n\nWhen I run \ngit log --parents --pretty=format:Commit:%H%nParent:%P%n%n alloc.c\nI get: \nCommit:4b25d091ba53c758fae0096b8c0662371857b9d9\nParent:100c5f3b0b27ec6617de1a785c4ff481e92636c1\n\nCommit:100c5f3b0b27ec6617de1a785c4ff481e92636c1\nParent:2c1cbec1e2f0bd7b15fe5e921d287babfd91c7d3\n\nCommit:2c1cbec1e2f0bd7b15fe5e921d287babfd91c7d3\nParent:579d1fbfaf25550254014fa472faac95f88eb779\n\nCommit:579d1fbfaf25550254014fa472faac95f88eb779\nParent:855419f764a65e92f1d5dd1b3d50ee987db1d9de\n\nCommit:855419f764a65e92f1d5dd1b3d50ee987db1d9de\nParent:\n\nWhen I try to run git log --parents --follow I get this:\ngit log --parents --follow --pretty=format:Commit:%H%nParent:%P%n%n alloc.c\n\nCommit:4b25d091ba53c758fae0096b8c0662371857b9d9\nParent:75b44066f3ed7cde238cdea1f0bf9e2f1744c820\n\nCommit:100c5f3b0b27ec6617de1a785c4ff481e92636c1\nParent:2c1cbec1e2f0bd7b15fe5e921d287babfd91c7d3\n\nCommit:2c1cbec1e2f0bd7b15fe5e921d287babfd91c7d3\nParent:f948792990f82a35bf0c98510e7511ef8acb9cd3\n\nCommit:579d1fbfaf25550254014fa472faac95f88eb779\nParent:446c6faec69f7ac521b8b9fc2b1874731729032f\n\nCommit:855419f764a65e92f1d5dd1b3d50ee987db1d9de\nParent:64e86c57867593ba0ee77a7b0ff0eb8e9d4d8ed5\n\nAs you can see git log --parents and git log --follow --parents produce very\ndifferent results, and as far as I can tell they should produce identical\noutputs. \n\nCould somebody tell me if I'm doing something wrong with the syntax? Or have\nI stumbled onto a quirk I fail to understand?\n\nThanks,\nAlbert \n"},{"id":"141627","messageId":"AANLkTilFn8qugzcGgr-Ooe5PZsSxmJOiubbG7sAwW1Ft@mail.gmail.com","threadId":"23804","inReplyTo":"006d01caf300$703e96a0$50bbc3e0$@burgmann.anu.edu.au","subject":"Re: Git log follow question","fromName":"Bo Yang","fromEmail":"struggleyb.nku@gmail.com","sentAt":"2010-05-14T04:16:13Z","receivedAt":"2010-05-14T04:16:13Z","isPatch":false,"sender":{"key":"struggleyb.nku@gmail.com","avatar":"https://avatars.githubusercontent.com/u/233030?v=4"},"body":"Hi Albert,\nOn Fri, May 14, 2010 at 8:57 AM, Albert Krawczyk\n<albert@burgmann.anu.edu.au> wrote:\n> As you can see git log --parents and git log --follow --parents produce very\n> different results, and as far as I can tell they should produce identical\n> outputs.\n>\n> Could somebody tell me if I'm doing something wrong with the syntax? Or have\n> I stumbled onto a quirk I fail to understand?\n\nThe problem you encountered is something about parent rewriting.\nThat's when git do a revision walk it will *modify* the actual parents\nof a commit according on the command line options.\nWhen you invoke, git log --parents , the parents rewriting mechanism\nis on. Take you have five commits:\ncommit1 <- commit2 <- commit3 <- 4 <- 5\nAnd only commit 5 and commit 2 change the file alloc.c. When you run\n'git log --parents alloc.c', the actual parent of commit 5 will be\nmodified to commit2. When you run git without --parents, commit 5's\nparent will still be commit 4.\nAnd when '--follow' is given, parent rewriting mechanism will be shut\ndown, so you get two different output.\n\nFor another words, I don't understand why we shut down the parent\nrewriting when '--follow' given. This make users confusing and also\nmake --graph inpossible to work with '--follow'...\n\nRegards!\nBo\n-- \nMy blog: http://blog.morebits.org\n"},{"id":"141628","messageId":"20100514043704.GC6075@coredump.intra.peff.net","threadId":"23804","inReplyTo":"006d01caf300$703e96a0$50bbc3e0$@burgmann.anu.edu.au","subject":"Re: Git log follow question","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-05-14T04:37:04Z","receivedAt":"2010-05-14T04:37:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 14, 2010 at 10:57:34AM +1000, Albert Krawczyk wrote:\n\n> I'm having an issue understanding the way git log --follow works with git\n> log --parents\n>\n> When I run\n> git log --parents --pretty=format:Commit:%H%nParent:%P%n%n alloc.c\n> I get:\n> Commit:4b25d091ba53c758fae0096b8c0662371857b9d9\n> Parent:100c5f3b0b27ec6617de1a785c4ff481e92636c1\n>\n> [...]\n>\n> When I try to run git log --parents --follow I get this:\n> git log --parents --follow --pretty=format:Commit:%H%nParent:%P%n%n alloc.c\n>\n> Commit:4b25d091ba53c758fae0096b8c0662371857b9d9\n> Parent:75b44066f3ed7cde238cdea1f0bf9e2f1744c820\n\nHmm. The actual parent is 75b44066. You get 100c5f in the first case\nbecause basic revision path-limiting simplifies the history graph to\nremove uninteresting commits (and rewrites the parents).\n\nSo the answer isn't _wrong_ exactly, but it is less useful. Seeing the\nsimplified graph is generally what we want. This is a limitation of the\nway --follow is implemented. It turns off history pruning because our\nlist of what to prune will be changing over time.\n\nProbably we would have to special-case the FOLLOW_RENAMES code to\nrewrite the parent list before display.\n\nI'm cc'ing Linus, who has more of a clue in both of those areas than I\ndo.\n\n-Peff\n"},{"id":"141629","messageId":"00a001caf31f$f837e970$e8a7bc50$@burgmann.anu.edu.au","threadId":"23804","inReplyTo":"21464_1273811837_4BECD37D_21464_745_1_20100514043704.GC6075@coredump.intra.peff.net","subject":"RE: Git log follow question","fromName":"Albert Krawczyk","fromEmail":"albert@burgmann.anu.edu.au","sentAt":"2010-05-14T04:43:16Z","receivedAt":"2010-05-14T04:43:16Z","isPatch":false,"sender":{"key":"albert@burgmann.anu.edu.au","avatar":null},"body":"Bo and Peff,\n\nThank you very much for your explanation. \n\nLinus, thanks in advance for looking at this.\n\nRegards,\nAlbert \n\n-----Original Message-----\nFrom: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Jeff King\nSent: Friday, 14 May 2010 2:37 PM\nTo: Albert Krawczyk\nCc: Linus Torvalds; git@vger.kernel.org\nSubject: Re: Git log follow question\n\nOn Fri, May 14, 2010 at 10:57:34AM +1000, Albert Krawczyk wrote:\n\n> I'm having an issue understanding the way git log --follow works with \n> git log --parents\n>\n> When I run\n> git log --parents --pretty=format:Commit:%H%nParent:%P%n%n alloc.c I \n> get:\n> Commit:4b25d091ba53c758fae0096b8c0662371857b9d9\n> Parent:100c5f3b0b27ec6617de1a785c4ff481e92636c1\n>\n> [...]\n>\n> When I try to run git log --parents --follow I get this:\n> git log --parents --follow --pretty=format:Commit:%H%nParent:%P%n%n \n> alloc.c\n>\n> Commit:4b25d091ba53c758fae0096b8c0662371857b9d9\n> Parent:75b44066f3ed7cde238cdea1f0bf9e2f1744c820\n\nHmm. The actual parent is 75b44066. You get 100c5f in the first case because basic revision path-limiting simplifies the history graph to remove uninteresting commits (and rewrites the parents).\n\nSo the answer isn't _wrong_ exactly, but it is less useful. Seeing the simplified graph is generally what we want. This is a limitation of the way --follow is implemented. It turns off history pruning because our list of what to prune will be changing over time.\n\nProbably we would have to special-case the FOLLOW_RENAMES code to rewrite the parent list before display.\n\nI'm cc'ing Linus, who has more of a clue in both of those areas than I do.\n\n-Peff\n--\nTo unsubscribe from this list: send the line \"unsubscribe git\" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"141671","messageId":"alpine.LFD.2.00.1005140730030.3711@i5.linux-foundation.org","threadId":"23804","inReplyTo":"20100514043704.GC6075@coredump.intra.peff.net","subject":"Re: Git log follow question","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-14T14:50:26Z","receivedAt":"2010-05-14T14:50:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 14 May 2010, Jeff King wrote:\n> \n> I'm cc'ing Linus, who has more of a clue in both of those areas than I\n> do.\n\nI'm pretty sure I mentioned about this exact issue when I posted the \noriginal follow patches, and it basically boils down to: \"--follow\" is a \ntotal hack, and does _not_ use the regular commit filtering function, and \nas a result, fancy things like \"--parent\" don't really work well with it.\n\nIOW, I'm not at all certain that it is fixable. \"--follow_ is a very \nfundamentally non-gitty thing to do, and really is a complete hack. It's a \nfairly _small_ hack - if you didn't know better and looked at the source \ncode, you might think that it fits very naturally into git. But no.\n\nNow, it's possible that we could hack up --parent to work with --follow \ntoo, but quite frankly, I don't know how. Because the --follow hack really \nbasically boils down to:\n\n - do _not_ prune commits at all (this the the thing that normally \n   simplifies the parenthood and removes uninteresting commits)\n\n - for the whole list of normal commits in \"git log\", do the patch \n   generation with a magic special hack that looks for renames.\n\n - if it was a rename, change the path that we magically track, so that \n   next commit that we look at, we'll follow the new (older) path.\n\n - if the patch is empty, we force-hide the commit (internally, this is \n   the \"rev->always_show_header = 0;\" thing)\n\nand the key here is that we do all the magic at the _end_ of the queue, \nlong after we've done the pruning of commits that normally does the \nparenthood renaming.\n\nIf we want --follow and --parent to work together, you'd need to move the \nspecial rename hack to be in the early phases. I'm sure it's possible. It \nmight even be reasonably simple. But it's very fundamentally not what we \ndo now.\n\nAnd no, I'm unlikely to look at it. Sorry. I have used --follow \noccasionally, but it's a hack to see \"ok, there it got renamed\". It would \nbe nice if \"gitk --follow <pathname>\" worked properly, but it's just not \nsomething I care very much about.\n\n\t\t\tLinus\n"},{"id":"141673","messageId":"AANLkTimfuINt0v_SETz9NsMGVXDL9d150B8En4TKqw3b@mail.gmail.com","threadId":"23804","inReplyTo":"alpine.LFD.2.00.1005140730030.3711@i5.linux-foundation.org","subject":"Re: Git log follow question","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2010-05-14T15:19:39Z","receivedAt":"2010-05-14T15:19:39Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Fri, May 14, 2010 at 10:50 AM, Linus Torvalds\n<torvalds@linux-foundation.org> wrote:\n> If we want --follow and --parent to work together, you'd need to move the\n> special rename hack to be in the early phases. I'm sure it's possible. It\n> might even be reasonably simple. But it's very fundamentally not what we\n> do now.\n...\n> It would\n> be nice if \"gitk --follow <pathname>\" worked properly, but it's just not\n> something I care very much about.\n\nPutting the internal machinery aside, it would be enormously useful\nfor the end user.\n\nThe Linux kernel is unusual in that there are relatively few renames /\nreorgs in the mainline -- maintainers pushback and force those things\nto happen before a patchset is merged. And you (as the lead\nmaintainer) probably know all the renames in your own project.\n\nThe use case for this is: \"Where the hell does this WTF-worthy\nfunction come from, in this WTF-esque old codebase I just inherited?\"\n\ncheers,\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- School Server Architect\n - ask interesting questions\n - don't get distracted with shiny stuff  - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"141674","messageId":"alpine.LFD.2.00.1005140827250.3711@i5.linux-foundation.org","threadId":"23804","inReplyTo":"AANLkTimfuINt0v_SETz9NsMGVXDL9d150B8En4TKqw3b@mail.gmail.com","subject":"Re: Git log follow question","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-14T15:29:23Z","receivedAt":"2010-05-14T15:29:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 14 May 2010, Martin Langhoff wrote:\n> \n> The use case for this is: \"Where the hell does this WTF-worthy\n> function come from, in this WTF-esque old codebase I just inherited?\"\n\nUmm. And git does that better than anything else. \n\n\"git log --follow\" works fine. As does \"git blame -C\".\n\nIt's just that gitk does not, because it wants to show the graph.\n\nAnyway, if you feel strongly about it, and really want \"gitk --follow\", \nyou really need to do it yourself. I gave you some pointers. I personally \ndon't think it's worth it.\n\n\t\tLinus\n"},{"id":"141707","messageId":"004001caf3b6$4f1082c0$ed318840$@burgmann.anu.edu.au","threadId":"23804","inReplyTo":"22729_1273851106_4BED6CE2_22729_6897_1_alpine.LFD.2.00.1005140827250.3711@i5.linux-foundation.org","subject":"RE: Git log follow question","fromName":"Albert Krawczyk","fromEmail":"albert@burgmann.anu.edu.au","sentAt":"2010-05-14T22:39:26Z","receivedAt":"2010-05-14T22:39:26Z","isPatch":false,"sender":{"key":"albert@burgmann.anu.edu.au","avatar":null},"body":"Hi,\n\nThank you everybody for your replies.\n\nI believe that this functionality would be useful; however, sadly my C\nskills are non-existent so I don't even know how to start looking at this\nproblem.\n\nI don't suppose there are other developers on here that would be interested\nin having a look at this functionality?\n\nThanks again,\nAlbert \n\n-----Original Message-----\nFrom: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf\nOf Linus Torvalds\nSent: Saturday, 15 May 2010 1:29 AM\nTo: Martin Langhoff\nCc: Jeff King; Albert Krawczyk; git@vger.kernel.org\nSubject: Re: Git log follow question\n\n\n\nOn Fri, 14 May 2010, Martin Langhoff wrote:\n> \n> The use case for this is: \"Where the hell does this WTF-worthy \n> function come from, in this WTF-esque old codebase I just inherited?\"\n\nUmm. And git does that better than anything else. \n\n\"git log --follow\" works fine. As does \"git blame -C\".\n\nIt's just that gitk does not, because it wants to show the graph.\n\nAnyway, if you feel strongly about it, and really want \"gitk --follow\", you\nreally need to do it yourself. I gave you some pointers. I personally don't\nthink it's worth it.\n\n\t\tLinus\n--\nTo unsubscribe from this list: send the line \"unsubscribe git\" in the body\nof a message to majordomo@vger.kernel.org More majordomo info at\nhttp://vger.kernel.org/majordomo-info.html\n"},{"id":"142271","messageId":"20100525093140.GA32460@coredump.intra.peff.net","threadId":"23804","inReplyTo":"alpine.LFD.2.00.1005140730030.3711@i5.linux-foundation.org","subject":"Re: Git log follow question","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-05-25T09:31:40Z","receivedAt":"2010-05-25T09:31:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 14, 2010 at 07:50:26AM -0700, Linus Torvalds wrote:\n\n> I'm pretty sure I mentioned about this exact issue when I posted the \n> original follow patches, and it basically boils down to: \"--follow\" is a \n> total hack, and does _not_ use the regular commit filtering function, and \n> as a result, fancy things like \"--parent\" don't really work well with it.\n>\n> [...]\n>\n> And no, I'm unlikely to look at it. Sorry. I have used --follow \n> occasionally, but it's a hack to see \"ok, there it got renamed\". It would \n> be nice if \"gitk --follow <pathname>\" worked properly, but it's just not \n> something I care very much about.\n\nThanks for the input. I took a look at it myself and it is a bit more\ncomplex than just turning on pruning. I have a prototype --follow that\nhandles arbitrary pathspecs instead of single files; instead of\nreplacing the single-file pathspec, it just widens the pathspec as it\ntraverses history. That eliminates some of the issues, but I am still\ngetting some odd results from --parents.\n\nSo I am giving up for now, as it is not something I care that much\nabout, either (though multiple-file --follow is). However, Bo Yang, one\nof the GSoC students, is planning on working on it as part of his\nline-level history browsing project. So we'll see what comes of that.\n\n-Peff\n"},{"id":"142292","messageId":"alpine.LFD.2.00.1005251141580.3689@i5.linux-foundation.org","threadId":"23804","inReplyTo":"20100525093140.GA32460@coredump.intra.peff.net","subject":"Re: Git log follow question","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-25T18:49:25Z","receivedAt":"2010-05-25T18:49:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 25 May 2010, Jeff King wrote:\n> \n> Thanks for the input. I took a look at it myself and it is a bit more\n> complex than just turning on pruning. I have a prototype --follow that\n> handles arbitrary pathspecs instead of single files; instead of\n> replacing the single-file pathspec, it just widens the pathspec as it\n> traverses history.\n\nDoing it \"right\" is actually a _lot_ more complex than that.\n\nThink especially about the case of the file having been renamed in one \nbranch, and in another branch it was created from scratch, and then a \nmerge that sorts it all out (think two people aiming for the same thing, \njust doing it differently - but with similar approaches).\n\nNow, imagine reaching the common commit by walking _one_ of the chains \nbefore having walked the other one fully. So now you're looking at a \ncommit using one set of pathnames, and then later on you'll hit the _same_ \ncommit (through the other branch), but with another set of pathnames. But \nby then you've already handled that commit.\n\nThe above isn't an issue with the regular pathname pruning, because the \npruning rules never change - so the order of handling commits never \nmatter, and you can do the pruning before/independently of having done any \nhistory following.\n\nAnd it's not an issue with the current total hack, because the current \ntotal hack doesn't even _try_ to handle it, and doesn't even really try to \ndo anything proper. The current hack is very much by design was a \"hey, \nthis is about as good as CVS/SVN could ever do\", rather than anything that \nhas any good design.\n\n\t\tLinus\n"},{"id":"142317","messageId":"20100526055823.GA30409@coredump.intra.peff.net","threadId":"23804","inReplyTo":"alpine.LFD.2.00.1005251141580.3689@i5.linux-foundation.org","subject":"Re: Git log follow question","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-05-26T05:58:23Z","receivedAt":"2010-05-26T05:58:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 25, 2010 at 11:49:25AM -0700, Linus Torvalds wrote:\n\n> On Tue, 25 May 2010, Jeff King wrote:\n> > \n> > Thanks for the input. I took a look at it myself and it is a bit more\n> > complex than just turning on pruning. I have a prototype --follow that\n> > handles arbitrary pathspecs instead of single files; instead of\n> > replacing the single-file pathspec, it just widens the pathspec as it\n> > traverses history.\n> \n> Doing it \"right\" is actually a _lot_ more complex than that.\n\nDid you mean doing history rewriting right is more complex than that, or\ndid you mean that handling multiple follow pathspecs is more complex\nthan pathspec-widening (where \"handling multiple pathspecs\" means making\n\"--follow subdir\" work about as well as \"--follow file\", but not\nactually doing real history rewriting)?\n\nIf the former, I agree.\n\nIf the latter, I am not sure it is any worse than the single-file follow\ncase.\n\nFor example, consider this history:\n\n  echo content >file && git add . && git commit -m base\n  git mv file new && git commit -m moved\n  sleep 1 ;# to ensure timestamp difference\n  git checkout -b other HEAD^\n  echo changes >>file && git commit -a -m changes\n  git merge master\n\nWe'll traverse in this order:\n\n  merge\n  changes (to file)\n  moved (from file to new)\n  base (create file)\n\nIf I do \"git log --follow new\" with the current master, I will see only\n\"moved\" and \"base\". I don't see \"changes\" because it operates on \"file\",\nnot \"new\". But if we reverse the order in which the two branches'\ncommits were made, then we will parse \"moved\" first, and we _will_ see\n\"changes\", because we've updated our pathspec. So it matters when we\ntraverse the rename.\n\nFor \"base\" and everything prior to it, in general we will already have\ntraversed the rename because we try to do things in date order. But in\nthe face of clock skew, it is possible to follow the ancestry down\nbefore hitting a rename on another branch.\n\nSo my point is that even with the current --follow, there are already\ncorner cases where traversal order matters. Which is maybe the point you\nwere trying to make, too, but I was unclear from your example if you\nmeant that the problem was _worse_ with simple expansion of pathspecs\n(i.e., not actually turning on revs->prune) than the current --follow.\n\n-Peff\n"},{"id":"142372","messageId":"alpine.LFD.2.00.1005260732490.3689@i5.linux-foundation.org","threadId":"23804","inReplyTo":"20100526055823.GA30409@coredump.intra.peff.net","subject":"Re: Git log follow question","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-26T14:40:22Z","receivedAt":"2010-05-26T14:40:22Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 26 May 2010, Jeff King wrote:\n> > \n> > Doing it \"right\" is actually a _lot_ more complex than that.\n> \n> Did you mean doing history rewriting right is more complex than that,\n\nHistory rewriting with changing pathspecs.\n\n> or did you mean that handling multiple follow pathspecs is more complex \n> than pathspec-widening\n\nNo, the \"expand pathspec to cover the newly found rename\" part is pretty \nsimple. But the fact that the pathspec changes over the history inevitably \nleads to the problem of finding commits in the right order.\n\nThe thing is, if the pathspec is history-dependent, then that means that \nin order to get it right, you should walk the history in topological order \nin order to get a proper pathspec. But you don't know what the topological \norder _is_ until you've walked the history - which in turn means that if \nyou want to get \"perfect\" results, you need to walk the history first, and \nthen have a separate phase to do the pathspec.\n\nThat's actually what the current --follow kind of does, but because the \ncurrent follow isn't even trying to get a proper pathspec in the bigger \npicture (it only tracks a single global filename rather than widening the \nnet), it also skips the topological part, since even if it did things in \ntopological order it would _still_ get things wrong.\n\nDoing it really right also actually would require making the pathspec be a \nper-commit thing rather than a single global one. Otherwise you get other \nodd effects, if that filename has ever been something different. But since \nyou only do a simple widening, I guess you don't much care (you already \nget odd effects if there was a criss-cross rename, and will end up picking \nup the history for _both_ files, rather than just the original one).\n\n\t\t\t\tLinus\n"}]}