commit IDs in changelog messsages (was: Introductory mail)

Sam Vilain sam at
Sun Nov 16 06:21:35 UTC 2008

On Thu, 2008-11-13 at 10:11 -0500, James Westby wrote:
> > No, why? Short commit IDs are usually enough in Git.
> Why not use [f] then?
> The short ID may be unambiguous when you create the entry, but it's not 
> future proof. The chances of a collision increase over time.

Right, but every digit you add you roughly quadruple the size the
project needs to get before a collision is likely.

Even with 7 digits on a large project you're likely to be safe, because
you know you're only looking at commit objects, and furthermore you know
the approximate date of the change from the changelog entry[1].

Only one in two projects with 20,000 commits will find a single
collision of 7 hex digit commit IDs; with 12, there's only a 0.1% chance
that you will find a collision with a hypothetical 1,000,000 commit

This is why it is common practice, and safe, to use shortened
identifiers in human-read and written locations.


1. git-rev-parse and friends don't currently have a mechanism for
disambiguating collisions with these hints, but that's just a patch or
two away should it be required.

More information about the vcs-pkg-discuss mailing list