Re: BUG: Git blame provides incorrect previous commit if the line is uncommitted

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 26, 2016, 16:05 UTC
Message-ID: <xmqqk2dyve7j.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAJxnqO6oMG2RvwP7y0Yt_xTrfeqqO6ZOUn5HWF7-h1hcjY+=bg@mail.gmail.com>

Eric Amodio <eamodio@gmail.com> writes:

Show 8 quoted lines

> This is the first time I've reported a bug with Git so please forgive
> me if this isn't the right place, format, etc.
>
> If git blame --porcelain (or --line-porcelain or --incremental) is run
> on a file that has uncommitted changes any uncommitted lines have the
> wrong previous sha. Instead of the sha the last time that line was
> changed or even the last time the file was changed it seem to return
> the last commit in the repository.

This is not limited to the case where uncommitted changes getting blamed to the working tree, I think. Replace C in the following description with "a fictional commit C that would have made as a direct child of HEAD if you were to commit all these uncommited changes" and read on.

When the command finds that a line is attributed to commit C, "previous" field in the internal data structure the command uses to keeps track of the ancestry is shown there. What the field means is this:

    The command compared C (the final answer) with this "previous"
    commit (typically a parent of it, but when you use -S or
    --reverse option it may be different), and it was found that C
    introduced this line.

So, no. "previous" is not "what would the result of running another 'git blame' on the state _before_ C to blame the general area?" It is meant as a hint for _you_ (rather, whatever tool is reading the incremental output) telling where to run another blame if you want to dig further, and it does not waste cycles to compute another blame on each and every output to show that before being asked.