bug#8756: 23.3; vc-git.el doesn't use --follow argument in vc-git-print-log

[Dan Nicolaescu <dann@gnu.org>]

Steinar Bang <sb@dod.no> writes:

>>>>>> Dan Nicolaescu <dann@gnu.org>:
>
>> The simple fix applied was suggested with the bug report.  It is not
>> enough to make it fully work, things like annotate, diff, etc do not
>> work...
>
> Indeed:
>  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756#8
>  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756#11
>
> To summarize: with --follow in place, what's listed in the log is the
> complete history, but annotate, and find files won't work past renames,
> and diffs reports "no diffs" when there should have been one (past
> renames).
>
> To summarize my experiments further down in the bug report thread: if
> you do  
>  git diff -M sha1a sha1b -- path-of-file-in-sha1a path-of-file-in-sha1b
> you get a result that is the diff of the two files.
>
> Here sha1a is a sha1 in "git log --follow path-of-file" that refers to a
> point in history before moving a file, and path-of-file-in-sha1a is the
> path to the file at that time in history.  And sha1b and
> path-of-file-in-sha1b refers to a point in time where the file has a
> different name or location.
>
> To get the sha1/path infomation one can do the command
>  git log --follow --name-only --pretty=oneline path-to-current-version-of-the-file
> and then parse out the sha1/path pairs.
>
> Note: this "git log" has to be done in addition to the displayed "git
> log".  This command is not for display, it is just to get the sha1/path
> pairs. 
>
> I have created an example repo that contains some renames, moves, and
> plain changes, at: https://github.com/steinarb/renametest.git
>
> Here is an example of a diff in that repository (in this case a file
> that has been renamed once, and then renamed file has been moved to a
> different location):
>
> sb@edwards:~/git/renametest$ git diff -M e5984c6a9e8e015dc521fb6a1756a88d5ffd676d 09d1bf6aa4dcd20dd36ca7668b75809e794428e0 -- hoved.txt application/main.txt
> diff --git a/hoved.txt b/application/main.txt
> similarity index 50%
> rename from hoved.txt
> rename to application/main.txt
> index 9a57969..7f5e5a6 100644
> --- a/hoved.txt
> +++ b/application/main.txt
> @@ -1,5 +1,6 @@
>  Hello world!
> -Version 1.0
> -Feature1 implementation
> +Version 2.0
>  Feature2 implementation
>  Feature3 implementation
> +Feature4 implementation
> +Feature4 implementation
>
>
> Here is an example of the command to get the sha1/path pairs:
> sb@edwards:~/git/renametest$ git log --follow --name-only --pretty=oneline application/main.txt

IMO the ideal solution is to get git to put the sha1/path info in the
log output, then vc can read it from there and do whatever is needed.
Is it possible to do that using the "format" argument to git log?

Another thing that could be improved in the log output (C-x v L) is to
put the date before the name.

From a random place in emacs history: 

* 2822e57..: Paul Eggert 2013-01-14 Avoid needless casts with XSAVE_POINTER.
* 5dece9d..: Leo Liu 2013-01-14 Sync window-point and point in calendar-redraw
* 9b1cf40..: Glenn Morris 2013-01-14 Auto-commit of loaddefs files.
* df32ded..: Dmitry Antipov 2013-01-14 * lisp.h (toplevel): Fix typo in comment.

The date has a fixed length, names do not, the display would look much better like this:

* 2822e57..: 2013-01-14 Paul Eggert  Avoid needless casts with XSAVE_POINTER.
* 5dece9d..: 2013-01-14 Leo Liu  Sync window-point and point in calendar-redraw
* 9b1cf40..: 2013-01-14 Glenn Morris  Auto-commit of loaddefs files.
* df32ded..: 2013-01-14 Dmitry Antipov  * lisp.h (toplevel): Fix typo in comment.