log: option "--follow" not the default for a single file?

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

On Tue, Nov 29, 2011 at 07:25:47PM +0100, Ralf Thielow wrote:

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

Jeff King <peff@peff.net> writes:

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.

Is it possible to detect the case of a single file in the current revisionand use "--follow" by default for exactly that?

On Wed, Nov 30, 2011 at 07:38:23PM +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.

-Peff

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.

On Thu, Dec 01, 2011 at 09:28:31PM +0100, Ralf Thielow wrote:

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.

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