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