HI, Jeff, Just double checking, the feature I suggested is fine, right? I will send the patch asap. It may take 2 weeks to implement. On Tue, Nov 26, 2019 at 4:36 PM chen bin <chenbin.sh@xxxxxxxxx> wrote: > > 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@xxxxxxxxx> 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@xxxxxxxx> 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. -- help me, help you.
