On Mar 21, 2012, at 1:51 PM, Thomas Rast wrote: > Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: > >> On Wed, Mar 21, 2012 at 4:22 PM, Thomas Gummerer <t.gummerer@xxxxxxxxx> wrote: >>> >>> On Mar 21, 2012, at 2:29 AM, Nguyen Thai Ngoc Duy wrote: >>> >>> However I got one more question, since I'm not yet really familiar with the >>> code and internal structure of git, what exactly does the SHA1 over the >>> index exactly achieve? Is it only for checking if the index is still correct >>> for the next time it is used and has not been changed or is there a more >>> important function of it? >> >> It makes sure the index is not corrupt (by disk faults for example). I >> don't think it is used for anything else. Cheaper checksum can be used >> if good enough for the index. See >> http://thread.gmane.org/gmane.comp.version-control.git/190016 and the >> following reply. > > Note that switching the checksum used already requires a > backwards-incompatible change of the index format. If we are going to > do that, I'm somewhat opposed to not also revising it along the lines > sketched by Shawn (at least). > > See my reply to Elton Sky > > http://thread.gmane.org/gmane.comp.version-control.git/193550/focus=193571 > > for links to some threads you may want to look at. While reworking the index into a tree (not to mention if it's in database format), the backward compatibility would be broken anyway from what I understood? Therefore taking Shawns thoughts into account should not be a lot more work and should make it also easier to implement for the .git reading programs, since it's easier to parse for the core it should also be easier to parse for them. Then if changing the checksum algorithm can bring some advantage I think it should be well worth the extra work while we break compatibility in any case. -- Thomas Gummerer -- 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