Got it. I will try to finish the patch first. On Wed, Nov 27, 2019 at 10:30 PM Jeff King <peff@xxxxxxxx> wrote: > > 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 -- help me, help you.
