Abbrevieated SHA1s (Was: Re: Process to push changes to include/linux/types.h)

[Stephen Rothwell <sfr@canb.auug.org.au>]

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

Hi Linus,

On Thu, 14 Oct 2010 15:13:27 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> Extended background for non-git people: git _internally_ only uses the
> 160-bit SHA1 (which in its full ASCII form is 40 hex characters). But
> because that is so human-unfriendly, there are various human-readable
> ways to express it:
> 
>  - Just a shortened unique version, usually 7-12 hex characters. 12
> hex characters is already unique in practice for pretty much any
> reasonable project, and is much easier to write.

I have had one case I hit where an abbreviated SHA1 (which may have been
only 7 hex chars) was unique in your tree, but not in linux-next :-(  I
think it was unique after one more character, though.   Having this
happen was a pain, because git reacted badly to being given a non-unique
SHA1 to look up.  i.e. it did *not* say the expected "this sha1 is not
unique".   However, now it does, so things are getting better.  It would
probably be nice if it told you the "matching" objects ...

So I would support using (at least) 12 char abbreviations in commit
messages (and any other long lived context).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]