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

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

[Ralf Thielow]

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

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

[Jeff King]

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

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

[Junio C Hamano]

Jeff King <peff@peff.net> 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.

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

[Ralf Thielow]

>     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?

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

[Jeff King]

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

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

[Ralf Thielow]

> 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.

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

[Jeff King]

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