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
