Re: [GSoC] Designing a faster index format - Progress report week 13

Junio C Hamano [off-list ref] writes:

Robin Rosenberg [off-list ref] writes:

quoted

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