Re: A new idea to extend git-blame

From: Jeff King <peff@peff.net>
Date: Nov 25, 2019, 14:16 UTC
Message-ID: <20191125141635.GD494@sigill.intra.peff.net>
In-Reply-To: <87o8x06sbw.fsf@sydneypc>

On Mon, Nov 25, 2019 at 11:41:55PM +1100, Chen Bin wrote:

Show 24 quoted lines

> 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