threads / discuss / 29033

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

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

## tl;dr

2 messages between Nov 28, 2011 and Nov 28, 2011.

replies: 1people: 2as markdown or json

Steinar Bang· Nov 28, 2011, 10:37 UTC · lore

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
Junio C Hamano· Nov 28, 2011, 19:53 UTC · re: Steinar Bang · lore

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

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

← back to recent threads