Re: A new idea to extend git-blame
From: chen bin <hidden>
Date: 2019-11-27 07:32:51
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 [off-list ref] 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 [off-list ref] wrote: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. 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 [off-list ref] wrote:quoted
On Mon, Nov 25, 2019 at 11:41:55PM +1100, Chen Bin wrote:quoted
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 1This 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.