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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html