On Thu, Oct 28, 2010 at 10:27 AM, Ted Ts'o [off-list ref] wrote:
On Thu, Oct 28, 2010 at 07:17:01PM +0200, Ingo Molnar wrote:
quoted
quoted
Linus Torvalds [off-list ref] 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