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

On Mon, Nov 10, 2014 at 4:39 AM, Torsten Bögershausen [off-list ref] wrote:

On 2014-11-08 10.39, Nguyễn Thái Ngọc Duy wrote:

quoted

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))

I don't see any generic way of detecting this. So I just save $(cwd)
and check if the repo is moved. False positive if you move your repo
within the same filesystem. If you move your stuff to a new filesystem
and mount it to the same place as before, my test fails.

quoted

 - 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.

If this link [1] is true and you use vfat on Linux, then we should
disable the cache when moving it to Windows.

[1] http://support.microsoft.com/kb/299648

quoted

 - 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!

For network fs, that's probably about it. For local fs, we still have
watchman option to speed it up a little more. Still not sure if I can
beat ".. made Mercurial's status command more than 5x faster than
Git's status command."

I am not really sure when we need this protection.
What I understand is that stat(dir).mtime must be reliable.

Yes and [1] shows that mtime is not reliable, at least on Windows+vfat.

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.

Old git should ignore (and discard) untr extension and go with the slow old way.
-- 
Duy