Seeing which commits modified a range of lines?

Seeing which commits modified a range of lines?

[Tom]

vc-annotate can show you the last commits which modified the lines in
a file. It is useful, but sometimes it would also be useful to see all
commits which touched a certain line or lines.

For example, seeing the changes which impacted a small function. Or
some block of code somewhere.

So I could select one or more consecutive lines and then call this
function which would list all the commits which modified some of these
selected lines, so I could see all changes that impacted this block of
code.

Can VC do this? If not then it could be a useful addition.

Re: Seeing which commits modified a range of lines?

[Tassilo Horn]

Tom <adatgyujto@gmail.com> writes:

Hi Tom,

> So I could select one or more consecutive lines and then call this
> function which would list all the commits which modified some of these
> selected lines, so I could see all changes that impacted this block of
> code.
>
> Can VC do this? If not then it could be a useful addition.

I don't think it can do this.  I've checked the docs for bzr log, hg
log, and git log, and it seems that git is the only one that can do what
you want, i.e., restrict the log to a range of lines in a file.  Well,
but if you use git, then this command should make you happy (only
briefly tested):

--8<---------------cut here---------------start------------->8---
(defun th/git-commits-on-region (beg end)
  (interactive "r")
  (let ((start-line (line-number-at-pos beg))
        (end-line (line-number-at-pos end)))
    (if (and (vc-root-dir)
             (eq 'Git (vc-backend buffer-file-name)))
        (let ((default-directory (vc-root-dir))
              (file (buffer-file-name))
              (buffer (get-buffer-create (format "*git commits touching %s, lines %d to %d*"
                                                 (buffer-file-name) start-line end-line))))
          (with-current-buffer buffer
            (erase-buffer)
            (call-process "git" nil t
                          t "log" "-L" (format "%d,%d:%s"
                                               start-line end-line
                                               (file-relative-name file)))
            (diff-mode)
            (goto-char (point-min)))
          (display-buffer buffer))
      (user-error "Cannot find a vc root directory or not a Git repo!"))))
--8<---------------cut here---------------end--------------->8---

Just mark the region you want the log for and do `M-x
th/git-commits-on-region RET'.  It'll create a buffer

  *git commits touching foo.el, lines 17 to 35*

which shows you the log messages and diffs modifying those lines in
`diff-mode'.

Bye,
Tassilo

Re: Seeing which commits modified a range of lines?

[Tom]

Tassilo Horn <tsdh <at> gnu.org> writes:

> 
> I don't think it can do this.  I've checked the docs for bzr log, hg
> log, and git log, and it seems that git is the only one that can do what
> you want, i.e., restrict the log to a range of lines in a file. 

Yes, it is usually not available built in, but it could be implemented
on top of blame as described in my answer to Stefan.

Re: Seeing which commits modified a range of lines?

[Tassilo Horn]

Tom <adatgyujto@gmail.com> writes:

>> I don't think it can do this.  I've checked the docs for bzr log, hg
>> log, and git log, and it seems that git is the only one that can do
>> what you want, i.e., restrict the log to a range of lines in a file.
>
> Yes, it is usually not available built in, but it could be implemented
> on top of blame as described in my answer to Stefan.

Yeah, or even better to implement it on top of "log" and "diff" because
"blame"/"annotate" is pretty slow.

Bye,
Tassilo

Re: Seeing which commits modified a range of lines?

[Tom]

Tassilo Horn <tsdh <at> gnu.org> writes:

> 
> Yeah, or even better to implement it on top of "log" and "diff" because
> "blame"/"annotate" is pretty slow.
> 

Of course it can be implemented with those as well.

And it could be a simple script layer before the command, so it
doesn't have to be implemented in elisp. And this script could
even be VC independent, only the backends needs to be VC 
dependent which call the proper commands for the given VC, but
the logic could be shared.

I'm suprised there is no existing solution for this. The feature
seems useful, the problem is interesting, so there should be at
least an attempt somewhere, even if the correct solution may be tricky.

Re: Seeing which commits modified a range of lines?

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

() Tom <adatgyujto@gmail.com>
() Thu, 6 Nov 2014 20:46:24 +0000 (UTC)

   I'm suprised there is no existing solution for this.
   The feature seems useful, the problem is interesting,
   so there should be at least an attempt somewhere, even
   if the correct solution may be tricky.

The classic (old-school, sadly out of fashion these days
of ever-widening programmer/non-programmer divide -- in
communication, in mindset, in action[0]) solution is to
grep ChangeLog files.

[0] The buzzword in PTB circles nowadays is "inclusion",
    a deliciously ironic idea for PTB, but no big news for
    some bottom-{br,n,w,f}eeding curmudgeon hackers...

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Seeing which commits modified a range of lines?

[Tom]

Thien-Thi Nguyen <ttn <at> gnu.org> writes:
> 
> The classic (old-school, sadly out of fashion these days
> of ever-widening programmer/non-programmer divide -- in
> communication, in mindset, in action[0]) solution is to
> grep ChangeLog files.

If you have a longer function which is modified a lot
of times and you are interested in a chunk of code in it
and want to see only its modifications then a feature
which can pinpoint the modifications in the chunk can be much
more useful than grepping the changelog.

Re: Seeing which commits modified a range of lines?

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

() Tom <adatgyujto@gmail.com>
() Fri, 7 Nov 2014 21:42:02 +0000 (UTC)

   If you have a longer function which is modified a lot
   of times and you are interested in a chunk of code in
   it and want to see only its modifications then a
   feature which can pinpoint the modifications in the
   chunk can be much more useful than grepping the
   changelog.

No doubt.  I address only the quality of the usefulness,
not its quantity, which (due to its Quality component) is
necessarily pov-specific.  My message was a semi-bitter
grousing response to the "I am surprised" bit, that's all.
[Insert nothing-gold-can-stay long-hair laments, here.  :-D]

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Seeing which commits modified a range of lines?

[Stefan Monnier]

> Can VC do this?

Currently, no.

> If not then it could be a useful addition.

Oh, yes, I've been dreaming of it ever since I started using GNU Arch.
IIUC the only tool which does provide the needed info is Git where
you have "git log -L<begline>,<endline>:<file>".


        Stefan

Re: Seeing which commits modified a range of lines?

[Tom]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
> Oh, yes, I've been dreaming of it ever since I started using GNU Arch.
> IIUC the only tool which does provide the needed info is Git where
> you have "git log -L<begline>,<endline>:<file>".
> 

Out of the box, yes, but the point of vc is to make the life of the
user easier and hide complexities. So this functionality could be 
implmented behind the scenes.

For example, VC tools provide annotate (blame) which can tell
the last change for lines in a file. So this can be called for
a file and then the last changes for the interesting lines 
are known.

Then blame can be called for these previous versions of the file
(indicated by the changes) to find out the last changes before
that, etc. so the  implementation can walk backwards the revisions
for each line collecting the commit infos and then finally 
presenting them to the user.

So it seems the information is available via annotate (blame),
because this is provided by the VC tools, so it may not be hard
to implement in a new vc command.

Re: Seeing which commits modified a range of lines?

[Stefan Monnier]

>> Oh, yes, I've been dreaming of it ever since I started using GNU Arch.
>> IIUC the only tool which does provide the needed info is Git where
>> you have "git log -L<begline>,<endline>:<file>".

BTW, I've just installed into trunk new code that gives access to this
functionality (called `vc-region-history' and which currently is only
supported for the Git backend).

> Out of the box, yes, but the point of vc is to make the life of the
> user easier and hide complexities.  So this functionality could be 
> implmented behind the scenes.

In theory, yes, but it can be pretty tedious to do (and the result can
be painfully slow) if done in Elisp.  In most cases it would be simpler
and much more efficient to implement it directly in the VCS tool.

> For example, VC tools provide annotate (blame) which can tell
> the last change for lines in a file.  So this can be called for
> a file and then the last changes for the interesting lines
> are known.

Actually, one of the reasons why I want vc-region-history is
specifically because annotate/blame does *not* always show you the
last revision.  The case where it doesn't is when you're looking for
a revision that just removed some lines.  Annotate/blame won't tell you
that between like N and N+1 there used to be some other lines and they
were removed in revision foo.

vc-region-history could be implemented for Bzr by running "bzr
log --show-diff" after which you "just" need to filter out the undesired
commits and patch hunks.

For a generic solution, you could write a loop that does:
- call annotate REV to find the last commit REV' that affected those lines.
- call diff between REV and REV' to adjust the line-numbers according to
  the changes that happened elsewhere in the mean time.
- call diff between REV'-1 and REV', filtering out the hunk that are
  outside of the affected region (and adjusting yet again the line numbers).
For most backends, such a loop will take forever to terminate (and of
course, it will miss some commits, as mentioned above).

An alternative is to do a "log" for the file, then a loop calling "diff"
for every revision in the log.  At that point you have the same data as
"bzr log --show-diff" and you can "just" filter out the commit and hunks
that don't affect the region.

Patch welcome.


        Stefan

Re: Seeing which commits modified a range of lines?

[Tom]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> For most backends, such a loop will take forever to terminate 

The termination problem could be mitigated by introducing 
a limit for the search. For example, after going back, say,
10 revisions (or if it's a time limit then after working for,
say, 5 seconds) the loop stops and emacs asks the user if
it should continue working or the user wants to see the 
results up to that point.

If the latter then the user can peruse the results and 
if more info is needed then he can restart the search 
which picks up where it left off using the previously 
collected info and continues working until the limit 
is reached again, etc.

Usually the user looks for some specific change impacting
that code chunk, so there is no need to go back to the 
beginning of time. If the user can control the process
the above described way then he goes back only as far
as needed, so the termination problem may be less of
an issue.

Re: Seeing which commits modified a range of lines?

[Stefan Monnier]

> The termination problem could be mitigated by introducing 
> a limit for the search. For example, after going back, say,

I'd update the buffer as the output appears, but it's still going to be
potentially very slow.  In any case, patches welcome.


        Stefan