On 2014-11-08 10.39, Nguyễn Thái Ngọc Duy wrote: > If the user enables untracked cache, then > > - move worktree to an unsupported filesystem How do we detect this move ? Shouldn't we be able to detect an unsupported file system (by probing if stat(root_dir_of_repo) == stat(what_we_have_in_index_file)) > - or simply upgrade OS > - or move the whole (portable) disk from one machine to another How does this effect Git ? I would rather expect an update of Git to be an issue, but knowing that Git strongly tends to be backward compatible, there shouldn't be a issue. > - or access a shared fs from another machine This is interesting. I have done some basic test on git.git using a medium fast laptop talking to a medium fast server using a medium normal WLAN. git status was is in a range of 2-3 seconds, with your patch 1-1.5 seconds. (That all depends on the network load, some caching here or there) But roughly twice the speed, very nice! I will do some tests with networking file systems, like Linux+ext4 -- SMB -- Windows (cygwin/Git for Windows) Linux+ext4 -- SMB -- Mac OS X Linux+ext4 -- NFS -- Linux Windows -- SMB -- Linux Windows -- SMB -- Mac OS X (and then we have some cases where a virtual machine runs a "shared" FS with a host file system, where the untracked cache looks promising) I am not really sure when we need this protection. What I understand is that stat(dir).mtime must be reliable. Another problem may be mixing old Git with new Git, but the old Git should write an index file without UNTR, and we should be safe ? The new Git will write an index file with UNTR, which the old Git will ignore. What do I miss ? -- 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