Re: git-blame vs. abbrev

[Junio C Hamano <gitster@pobox.com>]

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.

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, so a parser that insists on exact 12 hexdigits sounds like
a bug.

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 ;-).