Thread (1 message) 1 message, 1 author, 2016-06-15
  • (off-list ancestor, not in this archive)
  • Re: Git and GCC · Nix <hidden> · 2016-06-15

Re: Git and GCC

From: Nix <hidden>
Date: 2016-06-15 22:43:59

On 8 Dec 2007, Johannes Schindelin said:
Hi,

On Sat, 8 Dec 2007, J.C. Pizarro wrote:
quoted
On 2007/12/07, "Linus Torvalds" [off-list ref] wrote:
quoted
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.)
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help