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

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

 



On Mon, Nov 10, 2014 at 4:39 AM, Torsten Bögershausen <tboegi@xxxxxx> wrote:
> 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))

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.

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

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