Re: Git and GCC

From: Nix <nix@esperi.org.uk>
Date: Dec 15, 2007, 00:18 UTC
Message-ID: <877ijg6c9u.fsf@hades.wkstn.nix>
In-Reply-To: <Pine.LNX.4.64.0712081223070.27959@racer.site>

On 8 Dec 2007, Johannes Schindelin said:

Show 14 quoted lines

> Hi,
>
> On Sat, 8 Dec 2007, J.C. Pizarro wrote:
>
>> On 2007/12/07, "Linus Torvalds" <torvalds@linux-foundation.org> wrote:
>>
>> > SHA1 is almost totally insignificant on x86. It hardly shows up. But 
>> > we have a good optimized version there.
>> 
>> If SHA1 is slow then why dont he contribute adding Haval160 (3 rounds) 
>> that it's faster than SHA1? And to optimize still more it with SIMD 
>> instructions in kernelspace and userland.
>
> He said SHA-1 is insignificant.

Actually davem also said it *is* significant on SPARC. But of course J. C. Pizarro's suggested solution won't work because you can't just go around replacing SHA-1 in git with something else :) you could *add* new hashing methods, but you couldn't avoid SHA-1, and adding a new hashing method would bloat every object and every hash in objects like commits with an indication of which hashing method was in use.

(But you know this.)

>> 1.   "Don't compress this repo but compact this uncompressed repo
>>       using minimal spanning forest and deltas"

... and then you do a git-gc. Oops, now what?

... or perhaps you want to look something up in the pack. Now you have to unpack a large hunk of the whole damn thing.

Show 5 quoted lines

>> 2.   "After, compress this whole repo with LZMA (e.g. 48MiB) from 7zip before
>>       burning it to DVD for backup reasons or before replicating it to
>>	internet".
>
> Patches? ;-)

Replicating a pack to the internet is almost invariably replicating *parts* of a pack anyway, which reduces to the problem with option 1 above...

-- 
`The rest is a tale of post and counter-post.' --- Ian Rawlings
                                                   describes USENET