Is there a "--follow" equvalent argument to git-rev-list?

Is there a "--follow" equvalent argument to git-rev-list?

[Steinar Bang]

I'm trying to make emacs vc log (`C-x v l') show the full history of git
versioned files.

In my first attempt, I tried adding a "--follow" argument to "git log"
in the vc-git-print-log message.  This made `C-x v l' show the full log.

But the problem with this solution was that commands done from the log,
such as diffing (a very convenient way to do diffs, when the "version
numbers" are sha1 hashes...), showing a particular revision, or
annotating from that revision and back, didn't work.  See the comment at
the end of this bug:
 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756

Today I decided to take another peek at this, but vc-git.el in the emacs
23.1 version of the file, now uses "git rev-list" instead of "git log"
to get the revision list.

And "git rev-list" doesn't seem to have anything similar to
"--follow"...?  At least I haven't found it.

The man page doesn't contain the text "renam".

Guessing at what the man page has meant, I've tried adding the "--all"
and "--full-history" arguments, but `C-x v l' still only shows history
back to the last move.

Is there an argument to "git rev-list" that will make it track across
renames?  Or is this only possible with "git log --follow"?

Thanks!


- Steinar

Re: Is there a "--follow" equvalent argument to git-rev-list?

[Junio C Hamano]

[administrivia: do not use Mail-Followup-To here]

Steinar Bang <sb@dod.no> writes:

> Is there an argument to "git rev-list" that will make it track across
> renames?

There isn't, and it is more or less deliberate.

The "log --follow" is not meant as anything more than a checkbox hack. The
intended audience of "rev-list" is scripts that reads plumbing output and
it is expected to be capable of doing all of what "follow" does and more.
It can notice that the path you were following has disappeared at a
particular commit, see what other paths (notice the plural, which is not
what --follow does) in the older tree may have contributed the contents of
the newly added path by running "diff-tree -M" (or -C), etc. That way the
scripts can even notice a case where a file you were following originally
were two separate files that the commit merged into one, which "follow"
would never do.