Qual è l'utilità dei prevedibili SHA in git?

SHA vs. GUID

Da Il modello dell'oggetto Git , l'enfasi è mia:

• Git can quickly determine whether two objects are identical or not, just by comparing names.
• Since object names are computed the same way in every repository, the same content stored in two repositories will always be stored under the same name.
• Git can detect errors when it reads an object, by checking that the object's name is still the SHA1 hash of its contents.

Quindi, sì, è una protezione contro la corruzione. Ecco perché il GUID non funzionerà, è casuale e non dipende dai contenuti.

Checksum di cosa?

Sempre dallo stesso articolo:

It is important to note that this is very different from most SCM systems that you may be familiar with. Subversion, CVS, Perforce, Mercurial and the like all use Delta Storage systems - they store the differences between one commit and the next. Git does not do this - it stores a snapshot of what all the files in your project look like in this tree structure each time you commit. This is a very important concept to understand when using Git.

Git memorizza istantanee binarie, ma non delta, in blob oggetti. La struttura della directory e i nomi dei file sono memorizzati in tree oggetti. Una buona spiegazione può essere trovata qui: Git Internals - Git Objects

Git calcola i checksum SHA di questi oggetti, non i delta o i file originali. blob s contiene solo il contenuto dei file originali, mentre i nomi di questi file vanno in tree s.

Git di apprendimento

Se vuoi imparare git come utente, non devi conoscere gli interni. Al momento, uso Git da oltre 3 anni e non ho usato nessuna di queste informazioni in pratica neanche una volta. È bello sapere, ma non è obbligatorio.

Se sei interessato all'architettura generale di Git, leggi questo: Git in L'architettura delle applicazioni open source .

Linus Torvalds spiega il motivo dell'utilizzo di un hash SHA nella sua presentazione git a Google (A proposito: raccomando a tutti quelli che vogliono capire che cosa è tutto per guardarlo completamente):

| video | transcript |

Having a good hash is good for being able to trust your data, it happens to have some other good features, too, it means when we hash objects, we know the hash is well distributed and we do not have to worry about certain distribution issues. Internally it means from the implementation standpoint, we can trust that the hash is so good that we can use hashing algorithms and know there are no bad cases. So there are some reasons to like the cryptographic side too, but it's really about the ability to trust your data. I guarantee you, if you put your data in git, you can trust the fact that five years later, after it is converted from your harddisc to DVD to whatever new technology and you copied it along, five years later you can verify the data you get back out is the exact same data you put in. And that is something you really should look for in a source code management system.

One of the reasons I care is we actually had for the kernel a break-in on one of the BitKeeper sites, where people tried to corrupt the kernel source code repository, and BitKeeper actually caught it. BitKeeper did not have a really fancy hash at all, I think it is only 16-bit CRC, something like that. But it was good enough that you could actually see clumsy attempt, it was not cryptographically secure but it was hard enough in practice to overcome that it was caught immediately. But when that happens once to you, you got burned once, you do not ever want to get burned again. Maybe your projects aren't that important, my projects, they are important. There is a reason I care.

[...]

So maybe I am a cuckoo, maybe I am a bit crazy, and I care about security more than most people do. But the whole notion that I would give the master copy of source code that I trust and I care about so much I would give it to a third party is ludicrous. Not even Google. Not a way in Hell would I do that. I allow Google to have a copy of it, but I want to have something I know that nobody touched it. By the way I am not a great MIS person so disc corruption issue is definitely a case that I might worry about because I do not do backups, so it's Ok if I can then download it again from multiple trusted parties I can verify them against each other that part is really easy, I can verify them against hopefully that 20 bytes that I really really cared about, hopefully I have that in a few places. 20-byte is easier to track than 180MB. And corruption is less likely to hit those 20 bytes. If I have those 20 bytes, I can download a git repository from a completely untrusted source and I can guarantee that they did not do anything bad to it. That's a huge thing and that is something when you do hosted repositories for other people if you use subversion you are just not doing it right. You are not allowing them to sleep well at night. Of course, if you do it for 70... how many, 75,000 projects? Most of them are pretty small and not that important so it's Ok. That should make people feel better.

Quando si ospita il repository su un sito di terze parti, è possibile utilizzare l'hash crittografico di ogni revisione per assicurarsi che non lo abbiano manomesso. Quando cambiano solo un singolo byte, gli hash non si adatteranno più. Ciò significa che annotare di tanto in tanto l'hash delle tue revisioni HEAD ti impedisce di manipolare maliziosamente la tua base di codice, anche quando non esegui personalmente il tuo codice.