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
