Thread (1 message) 1 message, 1 author, 2016-09-26

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

From: Junio C Hamano <hidden>
Date: 2016-09-26 16:05:45

Eric Amodio [off-list ref] writes:
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help