A new idea to extend git-blame

> The key algorithm is simple,
> 
> The algorithm only works for one line blame and the user must
> select text inside the line first.
> 
> Step 1, `git blame -L6,1 --porcelain -- hello.js` output,
> 
>     4f87408612e0dacfd89a1cd2515944e21cf68561 6 6 1
>     skip...
>     filename hello.js
>      doit({bad: 'destroy world', good: 'hello world', ...});
> 
> I got the commit id (1st column), the line number (2nd column),
> file name (hello.js) and the code line (last line).
> 
> Step 2, if the code line does not contain the selected text, the
>   recursive search stops
> 
> Step 3, or else use commit id, line number and file name to build
>   new git blame cli, like,
> 
> `git blame -L line-num,1 --porcelain 4f8740^ file-name`
> 
> Step 4, execute new git blame command and start from Step 1

>
> On Mon, Nov 25, 2019 at 11:41:55PM +1100, Chen Bin wrote:
>
> > The key algorithm is simple,
> >
> > The algorithm only works for one line blame and the user must
> > select text inside the line first.
> >
> > Step 1, `git blame -L6,1 --porcelain -- hello.js` output,
> >
> >     4f87408612e0dacfd89a1cd2515944e21cf68561 6 6 1
> >     skip...
> >     filename hello.js
> >      doit({bad: 'destroy world', good: 'hello world', ...});
> >
> > I got the commit id (1st column), the line number (2nd column),
> > file name (hello.js) and the code line (last line).
> >
> > Step 2, if the code line does not contain the selected text, the
> >   recursive search stops
> >
> > Step 3, or else use commit id, line number and file name to build
> >   new git blame cli, like,
> >
> > `git blame -L line-num,1 --porcelain 4f8740^ file-name`
> >
> > Step 4, execute new git blame command and start from Step 1
>
> This sounds a lot like how git-log's "-L" option works, which tries to
> find the history of a line over many changes.
>
> It's also similar to the "re-blame from parent" feature of many blame
> viewers. There we have a human in the loop saying "no, this is not quite
> the change I'm looking for; go back further".
>
> -Peff

>
> I re-tested `git log -L20,20:README.md` in git's own repo with HEAD
> d01d26f2df. Looks git log is not what I expected. The output contains
> many unrelated commits. So it will be slow in real project.
>
> A recursive blame with the algorithm I suggest will get correct commit
> in short time. So my suggestion still hold.
>
> I could submit a patch to enhance blame.
>
> On Tue, Nov 26, 2019 at 1:16 AM Jeff King <peff@peff.net> wrote:
> >
> > On Mon, Nov 25, 2019 at 11:41:55PM +1100, Chen Bin wrote:
> >
> > > The key algorithm is simple,
> > >
> > > The algorithm only works for one line blame and the user must
> > > select text inside the line first.
> > >
> > > Step 1, `git blame -L6,1 --porcelain -- hello.js` output,
> > >
> > >     4f87408612e0dacfd89a1cd2515944e21cf68561 6 6 1
> > >     skip...
> > >     filename hello.js
> > >      doit({bad: 'destroy world', good: 'hello world', ...});
> > >
> > > I got the commit id (1st column), the line number (2nd column),
> > > file name (hello.js) and the code line (last line).
> > >
> > > Step 2, if the code line does not contain the selected text, the
> > >   recursive search stops
> > >
> > > Step 3, or else use commit id, line number and file name to build
> > >   new git blame cli, like,
> > >
> > > `git blame -L line-num,1 --porcelain 4f8740^ file-name`
> > >
> > > Step 4, execute new git blame command and start from Step 1
> >
> > This sounds a lot like how git-log's "-L" option works, which tries to
> > find the history of a line over many changes.
> >
> > It's also similar to the "re-blame from parent" feature of many blame
> > viewers. There we have a human in the loop saying "no, this is not quite
> > the change I'm looking for; go back further".
> >
> > -Peff
>
>
>
> --
> help me, help you.

>
> The problem of recursive blaming with 3rd party script is it's slow.
> The script have to restart git process multiple times. Besides, as I
> already did in Emacs (see
> https://github.com/redguardtoo/vc-msg/commit/1f7775f951fdd9e6571afbb3a767c42d20617f52),
> it's still lots of code.
>
> So if it's possible to use a simple cli option like `git blame
> -S"text"`to do the same thing, it would be easier to migrate vc-msg's
> functionality to other text editors.
>
> On Tue, Nov 26, 2019 at 3:55 PM chen bin <chenbin.sh@gmail.com> wrote:
> >
> > I re-tested `git log -L20,20:README.md` in git's own repo with HEAD
> > d01d26f2df. Looks git log is not what I expected. The output contains
> > many unrelated commits. So it will be slow in real project.
> >
> > A recursive blame with the algorithm I suggest will get correct commit
> > in short time. So my suggestion still hold.
> >
> > I could submit a patch to enhance blame.
> >
> > On Tue, Nov 26, 2019 at 1:16 AM Jeff King <peff@peff.net> wrote:
> > >
> > > On Mon, Nov 25, 2019 at 11:41:55PM +1100, Chen Bin wrote:
> > >
> > > > The key algorithm is simple,
> > > >
> > > > The algorithm only works for one line blame and the user must
> > > > select text inside the line first.
> > > >
> > > > Step 1, `git blame -L6,1 --porcelain -- hello.js` output,
> > > >
> > > >     4f87408612e0dacfd89a1cd2515944e21cf68561 6 6 1
> > > >     skip...
> > > >     filename hello.js
> > > >      doit({bad: 'destroy world', good: 'hello world', ...});
> > > >
> > > > I got the commit id (1st column), the line number (2nd column),
> > > > file name (hello.js) and the code line (last line).
> > > >
> > > > Step 2, if the code line does not contain the selected text, the
> > > >   recursive search stops
> > > >
> > > > Step 3, or else use commit id, line number and file name to build
> > > >   new git blame cli, like,
> > > >
> > > > `git blame -L line-num,1 --porcelain 4f8740^ file-name`
> > > >
> > > > Step 4, execute new git blame command and start from Step 1
> > >
> > > This sounds a lot like how git-log's "-L" option works, which tries to
> > > find the history of a line over many changes.
> > >
> > > It's also similar to the "re-blame from parent" feature of many blame
> > > viewers. There we have a human in the loop saying "no, this is not quite
> > > the change I'm looking for; go back further".
> > >
> > > -Peff
> >
> >
> >
> > --
> > help me, help you.
>
>
>
> --
> help me, help you.

>
> On Wed, Nov 27, 2019 at 06:32:37PM +1100, chen bin wrote:
>
> > Just double checking, the feature I suggested is fine, right? I will
> > send the patch asap. It may take 2 weeks to implement.
>
> To be clear, I can't say whether a patch is fine or not without seeing
> the patch. :)
>
> I'm not entirely sure I understand what you're proposing to implement.
> But if it's of interest to you, maybe it makes sense to see if you can
> make it work to your satisfaction, and then we can all look at the patch
> and what it does to see if it makes sense to include in Git?
>
> > > > I re-tested `git log -L20,20:README.md` in git's own repo with HEAD
> > > > d01d26f2df. Looks git log is not what I expected. The output contains
> > > > many unrelated commits. So it will be slow in real project.
>
> Looking at the output from that command, the issue is that it's
> imperfect to decide which lines in the pre- and post-image correspond to
> each other. The first commit is:
>
>   diff --git a/README.md b/README.md
>   --- a/README.md
>   +++ b/README.md
>   @@ -26,3 +26,1 @@
>   -See Documentation/gittutorial.txt to get started, then see
>   -Documentation/giteveryday.txt for a useful minimum set of commands, and
>   -Documentation/git-commandname.txt for documentation of each command.
>   +See [Documentation/gittutorial.txt][] to get started, then see
>
> at which point we consider all three of the pre-image lines to be
> potentially interestnig. And then the next commit:
>
>   diff --git a/README b/README
>   --- a/README
>   +++ b/README
>   @@ -29,3 +29,3 @@
>    See Documentation/gittutorial.txt to get started, then see
>   -Documentation/everyday.txt for a useful minimum set of commands, and
>   +Documentation/giteveryday.txt for a useful minimum set of commands, and
>    Documentation/git-commandname.txt for documentation of each command.
>
> touches one of those lines, and so forth. A human might see that in the
> first hunk, it was probably the first line of the hunk that was
> interesting to keep following backwards. But I don't think it can be
> done automatically (which is why manual "reblame from parent" is still a
> useful technique).
>
> It sounds like your suggestion is to take some anchor text on the line
> to decide which lines to keep following. But then it sounds a lot more
> like a "log -L" feature than a git-blame feature.
>
> -Peff

>
> On Wed, Nov 27, 2019 at 06:32:37PM +1100, chen bin wrote:
>
> > Just double checking, the feature I suggested is fine, right? I will
> > send the patch asap. It may take 2 weeks to implement.
>
> To be clear, I can't say whether a patch is fine or not without seeing
> the patch. :)
>
> I'm not entirely sure I understand what you're proposing to implement.
> But if it's of interest to you, maybe it makes sense to see if you can
> make it work to your satisfaction, and then we can all look at the patch
> and what it does to see if it makes sense to include in Git?
>
> > > > I re-tested `git log -L20,20:README.md` in git's own repo with HEAD
> > > > d01d26f2df. Looks git log is not what I expected. The output contains
> > > > many unrelated commits. So it will be slow in real project.
>
> Looking at the output from that command, the issue is that it's
> imperfect to decide which lines in the pre- and post-image correspond to
> each other. The first commit is:
>
>   diff --git a/README.md b/README.md
>   --- a/README.md
>   +++ b/README.md
>   @@ -26,3 +26,1 @@
>   -See Documentation/gittutorial.txt to get started, then see
>   -Documentation/giteveryday.txt for a useful minimum set of commands, and
>   -Documentation/git-commandname.txt for documentation of each command.
>   +See [Documentation/gittutorial.txt][] to get started, then see
>
> at which point we consider all three of the pre-image lines to be
> potentially interestnig. And then the next commit:
>
>   diff --git a/README b/README
>   --- a/README
>   +++ b/README
>   @@ -29,3 +29,3 @@
>    See Documentation/gittutorial.txt to get started, then see
>   -Documentation/everyday.txt for a useful minimum set of commands, and
>   +Documentation/giteveryday.txt for a useful minimum set of commands, and
>    Documentation/git-commandname.txt for documentation of each command.
>
> touches one of those lines, and so forth. A human might see that in the
> first hunk, it was probably the first line of the hunk that was
> interesting to keep following backwards. But I don't think it can be
> done automatically (which is why manual "reblame from parent" is still a
> useful technique).
>
> It sounds like your suggestion is to take some anchor text on the line
> to decide which lines to keep following. But then it sounds a lot more
> like a "log -L" feature than a git-blame feature.
>
> -Peff