Re: git-blame vs. abbrev

[Laszlo Ersek <laszlo.ersek@posteo.net>]

On 6/30/26 21:49, Junio C Hamano wrote:
> Laszlo Ersek <laszlo.ersek@posteo.net> writes:
>
>> Hi,
>>
>> when git-blame is passed the "-b" option ("Show blank SHA-1 for
>> boundary commits"), shouldn't git-blame *stop* reserving a commit
>> hash nibble for the caret that otherwise marks boundary commits?
>>
>> More directly, I find it inconvenient that git-blame shows commit
>> hashes that are one nibble longer (13) than my "core.abbrev" (12)
>> setting; that makes cutting and pasting commit hashes from the
>> git-blame output into a git-rebase TODO list cumbersome.
>
> I never knew that the parser in rebase did not want to see a longer
> abbreviation; shouldn't it take 16 hexadecimal abbreviation from the
> result of letting the user edit the list, even if it initially gave
> 12 hexadecimal abbreviation, as long as these extra 4 hexdigits do
> not break the commit object name?  That is a more serious usability
> bug that needs to be fixed, if it is the case, I would think.

Ugh, I'm very sorry; I failed to describe my problem precisely. When I
wrote "cutting and pasting commit hashes from the git-blame output into
a git-rebase TODO list", I actually meant pasting the commit hash from
git-blame into the *search box* of the editor that keeps the git-rebase
TODO list open.

Basically I want to fix up a line of code in a patch in a longer patch
set, but don't know off-hand which patch in the set introduces that line
of code. So git-blame gives me a commit hash, and subsequently, I run
git-rebase, would like to jump to the TODO line with that commit hash,
and change the action from "pick" to "edit". And this *lookup* is what
fails, because the hash from git-blame is 13 nibbles long, but the
hashes in the git-rebase TODO list are 12 nibbles long. I always have to
remember to remove the last nibble in the search box; otherwise, there
is no match.

> FWIW, even if your core.abbrev says you want 12, if two objects share
> the same 12 hexdigits as the prefix, you do end up getting 13 or more,

Indeed, but that does not matter in practice (to me anyway); a 12-nibble
prefix length suffices for very large projects, and if ever there were a
collision, I'd just increase the length permanently to 13 nibbles. The
specific length is not relevant; agreement between git-blame's output
and everything else dealing with commit hashes in git is what I'd like
very much.

> so a parser that insists on exact 12 hexdigits sounds like a bug.
>
Apologies again, that (implied) bug existed only between my chair and
keyboard. :)

> Just for the sake of aesthetics, I agree that when we are not showing
> the boundary mark, it would make sense not to reserve one column that
> we know we will never use.  But unless there is a mistaken parser that
> insists on 12 hexdigits when 13 hexdigits you give uniquely identify
> the same object, I suspect you wouldn't even notice that the
> hexadecimal digits you see on the screen have one digit longer than
> usual ;-).

That's it precisely! :) I do *not* notice that the hash from git-blame
has one more hexadecimal character than the central abbrev setting; so I
just go ahead and blindly cut n' paste it, using the mouse, from the
terminal, to the editor search box that's displaying the git-rebase TODO
list. And then I don't understand why the lookup fails (until I realize
that I have forgotten, yet again, to strip the last nibble from the
commit hash coming from git-blame).

Once again, sorry about misstating the problem / use case!

Laszlo