Re: git-blame vs. abbrev

Laszlo Ersek [off-list ref] 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 ;-).