What I did is "partial line blame", select partial line, do recursive blame,
stop when the selected text disappears.

There are screenshots at
http://blog.binchen.org/posts/effective-git-blame-in-emacs.html

I already implemented in Emacs Lisp. For now looks it works.

I understand `git log -L20,20:README.md` can track the change before `README`
is renamed to `README.md`. But my recursive blame code can't.

The problem is, `git log -L20,20:README.md` output too much text.
See https://gist.github.com/redguardtoo/a0c178350414449c45e6b67e16249000

It's difficult to track the correct commit if anchor text is generic
work like "true".

For example, the full text of line 20 in `README.md` (HEAD is d9f6f3b619 ) is,
`See [Documentation/gittutorial.txt][] to get started, then see`
To detect the commit adding the word `see`, the recursive blame algorithm stops
at commit 6164972018 because 6164972018^ rename `README` to `README.md`.

That's acceptable in real world because users can base the manual
blame on 6164972018.

But in the output of `git log command`, there are too many
"occurrence" of word "see" so it's
difficult to find the correct commit.

On Wed, Nov 27, 2019 at 10:30 PM Jeff King [off-list ref] wrote:

On Wed, Nov 27, 2019 at 06:32:37PM +1100, chen bin wrote:

quoted

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

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

-- 
help me, help you.