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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thomas Rast <trast@xxxxxxxxxxxxxxx> writes:

> 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....
> an argument in favor of splitting stat_crc into its fields again?

A difference is that JGit already has such code, and we would be
adding a burden to do so yet again.  It also may not just be JGit,
but anything that wants to be "compatible" with systems whose
filesystem interface does not give enough data by omitting fields
the current index pays attention to.

It isn't really a discussion about splitting again, but more about
not squishing them into a new field in the first place---IIUC, even
outside Windows, ctime is already problematic on some systems where
background processes muck with extended attributes Git does not pay
attention to. If the patch makes us lose the ability to selectively
ignore changes to certain fields (e.g. changes to dev and ino are
noticed but ctime are ignored) by squishing them into one new field,
wouldn't removing them without adding such a useless field a simpler
way to go?
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]