Messages in this thread | | | Date | Fri, 15 Oct 2010 14:03:19 +1100 | From | Stephen Rothwell <> | Subject | Abbrevieated SHA1s (Was: Re: Process to push changes to include/linux/types.h) |
| |
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/ [unhandled content-type:application/pgp-signature] | |