commit IDs in changelog messsages (was: Introductory mail)
sam at vilain.net
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.
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