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 repository. This is why it is common practice, and safe, to use shortened identifiers in human-read and written locations. Sam. 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. _______________________________________________ vcs-pkg-discuss mailing list email@example.com http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss