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?

quoted

quoted

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