Re: Distribution of longest common hash prefixes

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 3 Apr 2007, Junio C Hamano wrote:
> 
> Are you hinting to update sha1_name.c::get_sha1() so that we do
> not accept abbreviated non-commit object names?

No, but it might be nice if we had some fairly graceful way of handling 
abbreviated SHA1's that ended up being ambiguous (maybe they weren't 
ambiguous in the original context, but became ambiguous later).

Some way of just listing the alternatives, and sorting - and showing - by 
type (so that if you know it's supposed to be a commit, you can trivially 
pick it out from other objects that happen to collide in the first <n> 
digits).

Right now we can do it with

	git-rev-list --objects --all | grep '^<abbrev-sha1>'

but that's actually not even correct (maybe the reason sha1_name decided 
it was ambiguous was due to an _unreachable_ SHA1?), and it's also very 
inefficient.

We could have some helper that just looked things up (it's easy enough to 
look up all potential SHA1 matches both in the filesystem and in a 
pack-file - no need for any rev-list thing that lists all objects).

Is this a pressing concern? Absolutely not. I don't think we've ever had 
any real problems with this, and you *can* do it by hand with a bit of 
inefficient scripting right now..

			Linus