# log: option "--follow" not the default for a single file? 7 messages from 2011-11-29 to 2011-12-01. Participants: Ralf Thielow, Jeff King, Junio C Hamano. Thread: https://gitlist.dev/t/29043 ## Ralf Thielow, 2011-11-29 18:25 Subject: log: option "--follow" not the default for a single file? Message-ID: URL: https://gitlist.dev/e/CAN0XMOJsiw0c4j_LooRrj80CVVy0omGLUcjDg4QoD4mNS3y1GA%40mail.gmail.com ``` Why is the option "--follow" not the default if the log-command is used with a single file? Many GUI tools don't show me the full history of a single file if there was a rename in it. Thanks ``` ## Jeff King, 2011-11-30 06:37 Subject: Re: log: option "--follow" not the default for a single file? Message-ID: <20111130063743.GB5317@sigill.intra.peff.net> URL: https://gitlist.dev/e/20111130063743.GB5317%40sigill.intra.peff.net In-Reply-To: ``` On Tue, Nov 29, 2011 at 07:25:47PM +0100, Ralf Thielow wrote: > Why is the option "--follow" not the default if the log-command > is used with a single file? Many GUI tools don't show me the > full history of a single file if there was a rename in it. A few reasons, I think: 1. There is no such thing as giving log a single file. You give it a pathspec. That may happen to match a single file in the current revision, but to git it is actually a prefix-limiting pattern, and "git log foo" will match "foo" if it is a file, or "foo/bar" if it was a directory in a previous revision. 2. It can be slower than a regular traversal, since we have to do rename detection whenever we see a deletion. In practice I don't think it is much slower, though (mainly because files don't get moved all that much). 3. The implementation is a bit hacky. In particular, things like history simplification and parent rewriting won't work. So a GUI tool that tries to draw a graph will make a very ugly graph. Try looking at "gitk $file" and then "gitk --follow $file" in some repository (if you don't have gitk, try "git log --graph --oneline"). Even with a linear history, things look ugly: there are big gaps in the graph. But in a branch-y history, it's downright unreadable, as you have parallel disconnected lines of history next to each other. I think (1) and (3) are fixable by improving the implementation (making --follow respect pathspecs and not single files, and having it work at the history-simplification level). And then you might argue that (2) isn't a big deal, and we can turn on --follow all the time. -Peff ``` ## Junio C Hamano, 2011-11-30 18:27 Subject: Re: log: option "--follow" not the default for a single file? Message-ID: <7vipm1qxdd.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vipm1qxdd.fsf%40alter.siamese.dyndns.org In-Reply-To: <20111130063743.GB5317@sigill.intra.peff.net> ``` Jeff King writes: > 2. It can be slower than a regular traversal, since we have to do > rename detection whenever we see a deletion. In practice I don't > think it is much slower, though (mainly because files don't get > moved all that much). There is no difference between a regular traversal and a follow traversal while the path is still there. When a path disappear during a regular traversal, most likely the remaining traversal will yield nothing but the user has already seen what is there to see. If a follow traversal was in use, the user has seen the same as the regular traversal up to that point, we spend a bit of time in rename detection, and then we start showing the result of the traversal using an updated pathspec. I doubt that "slowness" is an issue here. ``` ## Ralf Thielow, 2011-11-30 18:38 Subject: Re: log: option "--follow" not the default for a single file? Message-ID: URL: https://gitlist.dev/e/CAN0XMOJGm1frOi7FEke7LfHCSBt2DRn_npkdKe0m3qZ%3DhQPNHw%40mail.gmail.com In-Reply-To: <20111130063743.GB5317@sigill.intra.peff.net> ``` >     pathspec. That may happen to match a single file in the current>     revision, but to git it is actually a prefix-limiting pattern, and Is it possible to detect the case of a single file in the current revisionand use "--follow" by default for exactly that? ``` ## Jeff King, 2011-12-01 18:52 Subject: Re: log: option "--follow" not the default for a single file? Message-ID: <20111201185230.GB2873@sigill.intra.peff.net> URL: https://gitlist.dev/e/20111201185230.GB2873%40sigill.intra.peff.net In-Reply-To: ``` On Wed, Nov 30, 2011 at 07:38:23PM +0100, Ralf Thielow wrote: > >     pathspec. That may happen to match a single file in the current > >     revision, but to git it is actually a prefix-limiting pattern, and > Is it possible to detect the case of a single file in the current > revisionand use "--follow" by default for exactly that? It's possible, but it is changing the meaning of "git log foo". With the current code, even if "foo" is currently a file, it will match "foo/bar" in a prior revision. Switching this to "--follow" will not. -Peff ``` ## Ralf Thielow, 2011-12-01 20:28 Subject: Re: log: option "--follow" not the default for a single file? Message-ID: URL: https://gitlist.dev/e/CAN0XMOKrCovkmmdqu2GjsDof0wehfbf5a0EQuPo0q7GQaJ%3DGRQ%40mail.gmail.com In-Reply-To: <20111201185230.GB2873@sigill.intra.peff.net> ``` > It's possible, but it is changing the meaning of "git log foo". With > the current code, even if "foo" is currently a file, it will match > "foo/bar" in a prior revision. Switching this to "--follow" will not. Why does it actually match both things? I think that's maybe wrong. The folder was moved or delete so it doesn't exist in my working directory. Also I can't use "git log" with another file/folder doesn't exists but in another revision. What actually exists is the file and that's imho the only thing that should match. ``` ## Jeff King, 2011-12-01 20:36 Subject: Re: log: option "--follow" not the default for a single file? Message-ID: <20111201203626.GA3659@sigill.intra.peff.net> URL: https://gitlist.dev/e/20111201203626.GA3659%40sigill.intra.peff.net In-Reply-To: ``` On Thu, Dec 01, 2011 at 09:28:31PM +0100, Ralf Thielow wrote: > > It's possible, but it is changing the meaning of "git log foo". With > > the current code, even if "foo" is currently a file, it will match > > "foo/bar" in a prior revision. Switching this to "--follow" will not. > > Why does it actually match both things? I think that's > maybe wrong. Because that's what the path argument to "git log" is designed to do -- limit revision traversal based on pathspecs. You can argue that the "--follow" semantics are more meaningful, but it doesn't change the fact that it is a behavior change. We have to consider not only backwards compatibility, but also the confusing-ness of an inconsistent interface where: git log foo bar will treat "foo" as a pathspec, but: git log foo will treat it as a file. > Also I can't use "git log" with another > file/folder doesn't exists but in another revision. What actually > exists is the file and that's imho the only thing that should match. You can: git log -- existed-long-ago As a syntax shortcut, you can drop the "--". However, there is some ambiguity with revision arguments, so git allows path arguments without a "--" only when they exist in the filesystem (_not_ in a particular revision). -Peff ```