GNU bug report logs -
#27953
vc-region-history doesn't follow renames
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 27953 in the body.
You can then email your comments to 27953 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
monnier <at> iro.umontreal.ca, bug-gnu-emacs <at> gnu.org:
bug#27953; Package
emacs.
(Fri, 04 Aug 2017 15:13:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Clément Pit--Claudel <clement.pitclaudel <at> live.com>:
New bug report received and forwarded. Copy sent to
monnier <at> iro.umontreal.ca, bug-gnu-emacs <at> gnu.org.
(Fri, 04 Aug 2017 15:13:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
X-Debbugs-CC: monnier <at> iro.umontreal.ca
Hi bug-gnu-emacs,
vc-git-region-history currently stops at the first rename, instead of continuing across renames. This is because it doesn't pass --follow to git. The original author put the required option "--follow" in a comment, adding "FIXME: not supported?".
Indeed, `git log -p --follow -L5,25:file.c' doesn't work. But `git log -p --follow -L5,25:file.c file.c' does work (note the extra mention of the file name).
Any arguments against the attached patch?
(CCing Stefan, since you're the last one who modified this function)
Clément.
[0001-Follow-renames-in-vc-git-region-history.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27953; Package
emacs.
(Fri, 04 Aug 2017 17:22:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 27953 <at> debbugs.gnu.org (full text, mbox):
> Indeed, `git log -p --follow -L5,25:file.c' doesn't work. But `git
> log -p --follow -L5,25:file.c file.c' does work (note the extra mention of
> the file name).
Hmm... what's the difference between
git log -p -L5,25:file.c
and
git log -p -L5,25:file.c file.c
?
Would this issue deserve a bug-report to Git?
> Any arguments against the attached patch?
I'd suggest to compute (file-relative-name file) only once, and to add
bug#27953 to the comment, but otherwise, looks good.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27953; Package
emacs.
(Fri, 04 Aug 2017 17:41:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 27953 <at> debbugs.gnu.org (full text, mbox):
On Aug 04 2017, Stefan Monnier <monnier <at> IRO.UMontreal.CA> wrote:
>> Indeed, `git log -p --follow -L5,25:file.c' doesn't work. But `git
>> log -p --follow -L5,25:file.c file.c' does work (note the extra mention of
>> the file name).
>
> Hmm... what's the difference between
>
> git log -p -L5,25:file.c
> and
> git log -p -L5,25:file.c file.c
The latter is supposed to be invalid:
-L <start>,<end>:<file>, -L :<funcname>:<file>
Trace the evolution of the line range given by "<start>,<end>" (or
the function name regex <funcname>) within the <file>. You may not
^^^^^^^^^^^
give any pathspec limiters.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Would this issue deserve a bug-report to Git?
It does.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27953; Package
emacs.
(Sat, 05 Aug 2017 13:07:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 27953 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2017-08-04 19:21, Stefan Monnier wrote:
>> Indeed, `git log -p --follow -L5,25:file.c' doesn't work. But `git
>> log -p --follow -L5,25:file.c file.c' does work (note the extra mention of
>> the file name).
>
> Hmm... what's the difference between
>
> git log -p -L5,25:file.c
> and
> git log -p -L5,25:file.c file.c
The second one allows --follow; the first one doesn't. I don't know what differences they may be beyond that :/
> Would this issue deserve a bug-report to Git?
Possibly; it's a bit intimidating.
>> Any arguments against the attached patch?
>
> I'd suggest to compute (file-relative-name file) only once, and to add
> bug#27953 to the comment, but otherwise, looks good.
Attached an updated version :)
Clément.
[0001-Follow-renames-in-vc-git-region-history.patch (text/x-patch, attachment)]
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27953; Package
emacs.
(Sat, 05 Aug 2017 17:07:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 27953 <at> debbugs.gnu.org (full text, mbox):
Clément Pit--Claudel <clement.pitclaudel <at> live.com> writes:
> On 2017-08-04 19:21, Stefan Monnier wrote:
>>> Indeed, `git log -p --follow -L5,25:file.c' doesn't work. But `git
>>> log -p --follow -L5,25:file.c file.c' does work (note the extra mention of
>>> the file name).
>>
>> Hmm... what's the difference between
>>
>> git log -p -L5,25:file.c
>> and
>> git log -p -L5,25:file.c file.c
>
> The second one allows --follow; the first one doesn't. I don't know what differences they may be beyond that :/
As Andreas mentioned, even though git doesn't throw an error, giving a
pathspec with -L is documented as invalid.
But you shouldn't need to add --follow here. Renames should be followed
by default when -L is used. (At least, that's what I see using Git
v2.13.3.)
--
Kyle
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27953; Package
emacs.
(Sat, 05 Aug 2017 17:24:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 27953 <at> debbugs.gnu.org (full text, mbox):
> From: Kyle Meyer <kyle <at> kyleam.com>
> Date: Sat, 05 Aug 2017 13:05:52 -0400
> Cc: Andreas Schwab <schwab <at> linux-m68k.org>,
> Stefan Monnier <monnier <at> IRO.UMontreal.CA>, 27953 <at> debbugs.gnu.org
>
> But you shouldn't need to add --follow here. Renames should be followed
> by default when -L is used. (At least, that's what I see using Git
> v2.13.3.)
I have 2.10 here, so maybe this was fixed later, but I don't see
renames followed when -L is used. E.g., try this:
git log -L77,83:admin/charsets/Makefile.in
You will see Git claiming the only version which changed that is the
one in which Makefile.in was created from Makefile. Am I doing
something wrong, or expecting too much?
Reply sent
to
Clément Pit--Claudel <clement.pitclaudel <at> live.com>:
You have taken responsibility.
(Sat, 05 Aug 2017 17:28:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Clément Pit--Claudel <clement.pitclaudel <at> live.com>:
bug acknowledged by developer.
(Sat, 05 Aug 2017 17:28:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 27953-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2017-08-05 19:05, Kyle Meyer wrote:
> Clément Pit--Claudel <clement.pitclaudel <at> live.com> writes:
>> On 2017-08-04 19:21, Stefan Monnier wrote:
>>>> Indeed, `git log -p --follow -L5,25:file.c' doesn't work. But `git
>>>> log -p --follow -L5,25:file.c file.c' does work (note the extra mention of
>>>> the file name).
>>>
>>> Hmm... what's the difference between
>>>
>>> git log -p -L5,25:file.c
>>> and
>>> git log -p -L5,25:file.c file.c
>>
>> The second one allows --follow; the first one doesn't. I don't know what differences they may be beyond that :/
>
> As Andreas mentioned, even though git doesn't throw an error, giving a
> pathspec with -L is documented as invalid.
Thanks. I'm glad I sent the patch for review.
> But you shouldn't need to add --follow here. Renames should be followed
> by default when -L is used. (At least, that's what I see using Git
> v2.13.3.)
This seems to be new. Adding --follow appears to make git follow renames here (2.7.4).
Thanks.
Clément.
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27953; Package
emacs.
(Sat, 05 Aug 2017 18:04:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 27953 <at> debbugs.gnu.org (full text, mbox):
On Aug 05 2017, Eli Zaretskii <eliz <at> gnu.org> wrote:
> I have 2.10 here, so maybe this was fixed later, but I don't see
> renames followed when -L is used. E.g., try this:
>
> git log -L77,83:admin/charsets/Makefile.in
>
> You will see Git claiming the only version which changed that is the
> one in which Makefile.in was created from Makefile. Am I doing
> something wrong, or expecting too much?
The problem is that admin/charsets/Makefile.in is only similar to
admin/charsets/Makefile by 32%, much below the default threshold. Try
lisp/obsolete/html2text.el instead, for example.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27953; Package
emacs.
(Sat, 05 Aug 2017 18:10:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 27953 <at> debbugs.gnu.org (full text, mbox):
On Aug 05 2017, Kyle Meyer <kyle <at> kyleam.com> wrote:
> But you shouldn't need to add --follow here. Renames should be followed
> by default when -L is used. (At least, that's what I see using Git
> v2.13.3.)
Note that the default for diff.renames has changed in 2.9. Earlier
versions may need to add -M.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27953; Package
emacs.
(Sat, 05 Aug 2017 18:28:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 27953 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: Kyle Meyer <kyle <at> kyleam.com>, clement.pitclaudel <at> live.com, monnier <at> IRO.UMontreal.CA, 27953 <at> debbugs.gnu.org
> Date: Sat, 05 Aug 2017 20:03:15 +0200
>
> > git log -L77,83:admin/charsets/Makefile.in
> >
> > You will see Git claiming the only version which changed that is the
> > one in which Makefile.in was created from Makefile. Am I doing
> > something wrong, or expecting too much?
>
> The problem is that admin/charsets/Makefile.in is only similar to
> admin/charsets/Makefile by 32%, much below the default threshold.
They look very similar to me...
What about doc/emacs/Makefile.in? That should be almost 100% similar
to its origin in man/Makefile.in, when it was moved from there, but
"git -L" still cannot cross the boundary.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27953; Package
emacs.
(Sat, 05 Aug 2017 20:08:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 27953 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> What about doc/emacs/Makefile.in? That should be almost 100% similar
> to its origin in man/Makefile.in, when it was moved from there, but
> "git -L" still cannot cross the boundary.
I believe the issue here is that the file was deleted in one commit
(19e364e29) and then added in another (8cf51b2c2).
--
Kyle
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#27953; Package
emacs.
(Sat, 05 Aug 2017 20:56:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 27953-done <at> debbugs.gnu.org (full text, mbox):
Clément Pit--Claudel <clement.pitclaudel <at> live.com> writes:
> On 2017-08-05 19:05, Kyle Meyer wrote:
[...]
>> But you shouldn't need to add --follow here. Renames should be followed
>> by default when -L is used. (At least, that's what I see using Git
>> v2.13.3.)
>
> This seems to be new. Adding --follow appears to make git follow renames here (2.7.4).
OK, just to check with a concrete example: When you run
git log -L37,57:test/lisp/ls-lisp-tests.el 9df49cddae
565cfd9f6 isn't listed as the earliest commit?
When I run that with Git 2.8.5 (and 2.13.3), I see 565cfd9f6 as the
earliest commit, indicating that Git does detect the rename
(test/lisp/ls-lisp.el => test/lisp/ls-lisp-tests.el). I wasn't able to
try with your version, 2.7.4, because I couldn't get it to build.
--
Kyle
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 03 Sep 2017 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 7 years and 348 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.