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

From: Thomas Rast <trast@student.ethz.ch>
Date: Jul 22, 2012, 19:43 UTC
Message-ID: <87629fvaxz.fsf@thomas.inf.ethz.ch>
In-Reply-To: <7vfw8jsk5o.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 13 quoted lines

> Robin Rosenberg <robin.rosenberg@dewire.com> 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