Re: [IGNORETHIS/PATCH] Choosing the sha1 prefix of your commits

From: Jeff King <peff@peff.net>
Date: Oct 20, 2011, 04:25 UTC
Message-ID: <20111020042559.GA5466@sigill.intra.peff.net>
In-Reply-To: <CAGZ=bqK2oVPxW3mm-WHMd1+KSiPquympJyhRqLWr1F=G74p+BA@mail.gmail.com>

On Thu, Oct 20, 2011 at 12:15:03AM -0400, Kyle Moffett wrote:

Show 11 quoted lines

> On Wed, Oct 19, 2011 at 22:51, Jeff King <peff@peff.net> wrote:
> > Keep in mind that each hex character you add increases the search space
> > by a factor of 16. deadbeef took about 70 seconds to find on my machine.
> > I'm tempted to look for "3133700..0031337", but it would probably
> > take about 4 hours.
> 
> Heh, there's one other practical downside I can think of...
> 
> If you create a bunch of commits with the same 8-hex-character prefix
> then suddenly the "git describe" logic for using the first 7 commit ID
> characters gets a whole lot less useful.

Actually, git will generally find a unique abbreviation among all of your objects when using abbreviated sha1s, so you'll just get longer abbreviations. Of course, it is only unique at the time of generation, so new objects may make it ambiguous. Which is why the default minimum is 7, not 1. But of course with this trick you've effectively removed all of the entropy from those initial 7 characters, and you effectively only have 1 or 2 non-uniform characters.

So yeah, it is worse. But really...spending millions of CPU cycles to get a preimage collision with the partial sha1, and hack-ishly embedding random crap after a NUL in every commit message, and _this_ is your complaint? ;)

-Peff