Junio C Hamano <[email protected]> writes:
> Robin Rosenberg <[email protected]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
