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

From: Jeff King <peff@peff.net>
Date: Dec 1, 2011, 20:36 UTC
Message-ID: <20111201203626.GA3659@sigill.intra.peff.net>
In-Reply-To: <CAN0XMOKrCovkmmdqu2GjsDof0wehfbf5a0EQuPo0q7GQaJ=GRQ@mail.gmail.com>

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

Show 6 quoted lines

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