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 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 vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss