From: Thomas Rast Date: Sun, 22 Jul 2012 19:43:20 GMT Subject: Re: [GSoC] Designing a faster index format - Progress report week 13 Message-ID: <87629fvaxz.fsf@thomas.inf.ethz.ch> In-Reply-To: <7vfw8jsk5o.fsf@alter.siamese.dyndns.org> Junio C Hamano writes: > Robin Rosenberg writes: > >> A note on how JGit would work here. Java has none of the fields >> that constitute statcrc. I guess we would write zero here when >> creating new entries. Git could recognize that when checking status >> and simply assume "clean" unless mtime or st_size says otherwise. > > Even though it may not be the end of the world, that is certainly > bad. Recording the constituent fields separately without the statcrc > microoptimization, thereby not shaving a handful of bytes per the > index entry, is not the end of the world either in the same sense, > which leads us to question the benefit we would be getting from such > a change. Hum, I'm a bit lost now. What is the status quo? I take it JGit does not have any of ctime, dev, ino etc., and either leaves the existing value or puts a 0. Which is not different from either leaving the stat crc in place, or putting a 0. Except that IIUC, putting a 0 in both cases means forcing a refresh once C git comes along (or some other reader that knows about the fields). So if we want to keep the safety net, a magic "I don't know" value would indeed be a good idea. But I don't see how what Robin said constitutes an argument in favor of splitting stat_crc into its fields again? -- Thomas Rast trast@{inf,student}.ethz.ch