On Thu, Oct 28, 2010 at 10:27 AM, Ted Ts'o wrote: > On Thu, Oct 28, 2010 at 07:17:01PM +0200, Ingo Molnar wrote: >> > Linus Torvalds wrote: >> > Yes. Except for the kernel the default git commit abbreviation is >> > borderline too short. Seven hex-chars can easily alias with a few >> > more pulls from me: git will not give aliases at the time it gives >> > a shorthand, but a month or two later the abbreviated commit may >> > no longer be unique. >> > >> > So I suggest using --abbrev=12 or similar. >> >> ok. A helper script i use does this: >> >>    git log --pretty=format:"%h: %s" $@ >> >> I have added --abbrev=12. Might make sense to lengthen the %h >> default in upstream Git as well? > > Maybe the right thing to do is add a git config option which allows > for a configurable minimum git commit abbreviation length? Yes. The default of 7 (I think) comes from fairly early in git development, when seven hex digits was a lot (it covers about 250+ million hash values). Back then I thought that 65k revisions was a lot (it was what we were about to hit in BK), and each revision tends to be about 5-10 new objects or so, so a million objects was a big number. These days, the kernel isn't even the largest git project, and even the kernel has about 220k revisions (_much_ bigger than the BK tree ever was) and we are approaching two million objects. At that point, seven hex digits is still unique for a lot of them, but when we're talking about just two orders of magnitude difference between number of objects and the hash size, there _will_ be hash collisions. It's no longer even close to unrealistic - it happens all the time. So I suspect we should both increase the default abbrev that was unrealistically small, _and_ add a way for people to set their own default per-project in the git config file. Maybe something like the attached (not necessarily well-thought-out or well-tested: I also didn't actually change the default, although I suspect we should up it from 7 to at least 10). Linus