On Thu, Oct 20, 2011 at 12:15:03AM -0400, Kyle Moffett wrote: > On Wed, Oct 19, 2011 at 22:51, Jeff King <peff@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html