On 10.12.14 13:22, Duy Nguyen wrote: > On Wed, Dec 10, 2014 at 12:08 PM, Torsten Bögershausen <tboegi@xxxxxx> wrote: >> That opens another question: >> How flexible/extensible/self-describing is the format of the UNTR extension >> ? >> If we drop the OS name & root dir check because it disallows network use, >> but later add a better method to verify that the underlying chain >> local OS - network - remote OS-remote FS is OK, >> do we need to change the file format of UNTR ? >> If yes, can old clients read the new format and vice versa? >> Do we need a version information of some kind, or does the >> old client skip unknown entries like we do with extensions in the index ? > The way index extensions are done so far, there's no actual versioning > inside an extension.Once an extension is out, its format is set in > stone. If you change your mind, you make a new extension (with a > different signature), so signatures are sort of "version". Code is > shared mostly so it should not be a problem. Old clients don't > recognize new extensions, so they drop them. New clients either stick > to old extensions or convert them to new ones. This is all local > matters, so I don't think we need to worry too much. Thanks for the info. Even if I share the the concerns that the cache may work on one system, but not on the other, there should be better ways to protect from that. Using the uname does not really help, if you move one repo from NTFS to VFAT, we will not detect it (assuming we use Windows). (And how much do we need to support the move of a repo ?) There is a concern that this may not work, when different clients are accessing the repo, using the UNTR extension. Some kind of sanity check would be good to have, what can be done ? The most important things are the timestamps. I can think of 2 sanity checks: - If the modified time stamp of a directory is older then the create time of any file, the UNTR cache can not be used. - If the timestamp of a file changes, but the sha1 sum is the same, what does this mean? The file (or the whole repo) has been copied, or the time stamping does not work. A simple verification of the FS could be to stat() .git/, create a temp file, delete it and stat() again. If mtime does not change, the FS is unusable for UNTR. Then we could extend the uname idea: Create a string in UNTR which is a collection of lines like this: Working-For: Linux;/mnt/nfs/projects/project1 Not-OK-For: WIndows:/a:/project1 (Of course the strings can be made nicer, and '\n' is URL-encoded.) Each system that is not listed needs to probe the repo, add another line and re-write the index. We can even add a "best-for" line, and invalidate the UNTR every 12 hours or so. Should we think about having an ASCII area for additional information, which is part of the stone, but the content is flexible ? The patch-series really speeds up "git status" on a network, thanks for working on it. The next days^H^H^H^H weeks I will do some more tests, using different combinations of OS and network protocols. -- 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