{"thread":{"id":"29043","subject":"log: option \"--follow\" not the default for a single file?","startedAt":"2011-11-29T18:25:47Z","lastAt":"2011-12-01T20:36:27Z","messageCount":7,"participants":["Ralf Thielow","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"180100","messageId":"CAN0XMOJsiw0c4j_LooRrj80CVVy0omGLUcjDg4QoD4mNS3y1GA@mail.gmail.com","threadId":"29043","inReplyTo":null,"subject":"log: option \"--follow\" not the default for a single file?","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@googlemail.com","sentAt":"2011-11-29T18:25:47Z","receivedAt":"2011-11-29T18:25:47Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"Why is the option \"--follow\" not the default if the log-command\nis used with a single file? Many GUI tools don't show me the\nfull history of a single file if there was a rename in it.\n\nThanks\n"},{"id":"180136","messageId":"20111130063743.GB5317@sigill.intra.peff.net","threadId":"29043","inReplyTo":"CAN0XMOJsiw0c4j_LooRrj80CVVy0omGLUcjDg4QoD4mNS3y1GA@mail.gmail.com","subject":"Re: log: option \"--follow\" not the default for a single file?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-11-30T06:37:43Z","receivedAt":"2011-11-30T06:37:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 29, 2011 at 07:25:47PM +0100, Ralf Thielow wrote:\n\n> Why is the option \"--follow\" not the default if the log-command\n> is used with a single file? Many GUI tools don't show me the\n> full history of a single file if there was a rename in it.\n\nA few reasons, I think:\n\n 1. There is no such thing as giving log a single file. You give it a\n pathspec. That may happen to match a single file in the current\n revision, but to git it is actually a prefix-limiting pattern, and\n \"git log foo\" will match \"foo\" if it is a file, or \"foo/bar\" if it\n was a directory in a previous revision.\n\n 2. It can be slower than a regular traversal, since we have to do\n rename detection whenever we see a deletion. In practice I don't\n think it is much slower, though (mainly because files don't get\n moved all that much).\n\n 3. The implementation is a bit hacky. In particular, things like\n history simplification and parent rewriting won't work. So a\n GUI tool that tries to draw a graph will make a very ugly graph.\n\n Try looking at \"gitk $file\" and then \"gitk --follow $file\" in some\n repository (if you don't have gitk, try \"git log --graph\n --oneline\"). Even with a linear history, things look ugly: there\n are big gaps in the graph. But in a branch-y history, it's\n downright unreadable, as you have parallel disconnected lines of\n history next to each other.\n\nI think (1) and (3) are fixable by improving the implementation (making\n--follow respect pathspecs and not single files, and having it work at\nthe history-simplification level). And then you might argue that (2)\nisn't a big deal, and we can turn on --follow all the time.\n\n-Peff\n"},{"id":"180162","messageId":"7vipm1qxdd.fsf@alter.siamese.dyndns.org","threadId":"29043","inReplyTo":"20111130063743.GB5317@sigill.intra.peff.net","subject":"Re: log: option \"--follow\" not the default for a single file?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-11-30T18:27:26Z","receivedAt":"2011-11-30T18:27:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> 2. It can be slower than a regular traversal, since we have to do\n> rename detection whenever we see a deletion. In practice I don't\n> think it is much slower, though (mainly because files don't get\n> moved all that much).\n\nThere is no difference between a regular traversal and a follow traversal\nwhile the path is still there. When a path disappear during a regular\ntraversal, most likely the remaining traversal will yield nothing but the\nuser has already seen what is there to see. If a follow traversal was in\nuse, the user has seen the same as the regular traversal up to that point,\nwe spend a bit of time in rename detection, and then we start showing the\nresult of the traversal using an updated pathspec. I doubt that \"slowness\"\nis an issue here.\n"},{"id":"180163","messageId":"CAN0XMOJGm1frOi7FEke7LfHCSBt2DRn_npkdKe0m3qZ=hQPNHw@mail.gmail.com","threadId":"29043","inReplyTo":"20111130063743.GB5317@sigill.intra.peff.net","subject":"Re: log: option \"--follow\" not the default for a single file?","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@googlemail.com","sentAt":"2011-11-30T18:38:23Z","receivedAt":"2011-11-30T18:38:23Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":">     pathspec. That may happen to match a single file in the current>     revision, but to git it is actually a prefix-limiting pattern, and\nIs it possible to detect the case of a single file in the current\nrevisionand use \"--follow\" by default for exactly that?\n"},{"id":"180212","messageId":"20111201185230.GB2873@sigill.intra.peff.net","threadId":"29043","inReplyTo":"CAN0XMOJGm1frOi7FEke7LfHCSBt2DRn_npkdKe0m3qZ=hQPNHw@mail.gmail.com","subject":"Re: log: option \"--follow\" not the default for a single file?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-12-01T18:52:30Z","receivedAt":"2011-12-01T18:52:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 30, 2011 at 07:38:23PM +0100, Ralf Thielow wrote:\n\n> >     pathspec. That may happen to match a single file in the current\n> >     revision, but to git it is actually a prefix-limiting pattern, and\n> Is it possible to detect the case of a single file in the current\n> revisionand use \"--follow\" by default for exactly that?\n\nIt's possible, but it is changing the meaning of \"git log foo\". With\nthe current code, even if \"foo\" is currently a file, it will match\n\"foo/bar\" in a prior revision. Switching this to \"--follow\" will not.\n\n-Peff\n"},{"id":"180217","messageId":"CAN0XMOKrCovkmmdqu2GjsDof0wehfbf5a0EQuPo0q7GQaJ=GRQ@mail.gmail.com","threadId":"29043","inReplyTo":"20111201185230.GB2873@sigill.intra.peff.net","subject":"Re: log: option \"--follow\" not the default for a single file?","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@googlemail.com","sentAt":"2011-12-01T20:28:31Z","receivedAt":"2011-12-01T20:28:31Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"> It's possible, but it is changing the meaning of \"git log foo\". With\n> the current code, even if \"foo\" is currently a file, it will match\n> \"foo/bar\" in a prior revision. Switching this to \"--follow\" will not.\n\nWhy does it actually match both things? I think that's\nmaybe wrong.\nThe folder was moved or delete so it doesn't exist in my\nworking directory. Also I can't use \"git log\" with another\nfile/folder doesn't exists but in another revision. What actually\nexists is the file and that's imho the only thing that should match.\n"},{"id":"180218","messageId":"20111201203626.GA3659@sigill.intra.peff.net","threadId":"29043","inReplyTo":"CAN0XMOKrCovkmmdqu2GjsDof0wehfbf5a0EQuPo0q7GQaJ=GRQ@mail.gmail.com","subject":"Re: log: option \"--follow\" not the default for a single file?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-12-01T20:36:27Z","receivedAt":"2011-12-01T20:36:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Dec 01, 2011 at 09:28:31PM +0100, Ralf Thielow wrote:\n\n> > It's possible, but it is changing the meaning of \"git log foo\". With\n> > the current code, even if \"foo\" is currently a file, it will match\n> > \"foo/bar\" in a prior revision. Switching this to \"--follow\" will not.\n> \n> Why does it actually match both things? I think that's\n> maybe wrong.\n\nBecause that's what the path argument to \"git log\" is designed to do --\nlimit revision traversal based on pathspecs.\n\nYou can argue that the \"--follow\" semantics are more meaningful, but it\ndoesn't change the fact that it is a behavior change. We have to\nconsider not only backwards compatibility, but also the confusing-ness\nof an inconsistent interface where:\n\n git log foo bar\n\nwill treat \"foo\" as a pathspec, but:\n\n git log foo\n\nwill treat it as a file.\n\n> Also I can't use \"git log\" with another\n> file/folder doesn't exists but in another revision. What actually\n> exists is the file and that's imho the only thing that should match.\n\nYou can:\n\n git log -- existed-long-ago\n\nAs a syntax shortcut, you can drop the \"--\". However, there is some\nambiguity with revision arguments, so git allows path arguments without\na \"--\" only when they exist in the filesystem (_not_ in a particular\nrevision).\n\n-Peff\n"}]}