Re: [PATCH v2 22/22] untracked cache: guard and disable on system changes

["Torsten Bögershausen" <tboegi@web.de>]

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 ?