Hacker News Reader

Comment by bicolao | Hacker News Reader

Because it relies on filesystem changing directory's mtime every time a file/dir is added or deleted in that directory. Not every filesystem supports that.

View on HN

Can't git just check whether the filesystem does this?

It would be a pity if an ignorant user copied a repository to another filesystem only to find out that certain operations suddenly break.

Perhaps the option should include the filesystem UUID for which the option should apply (to prevent these kinds of surprises).

>Can't git just check whether the filesystem does this?

it can by using `git update-index --test-untracked-cache` but it takes a long time to check this, so I guess they don't want to incur that penalty on every run.

OTOH,

>It would be a pity if an ignorant user copied a repository to another filesystem only to find out that certain operations suddenly break.

yes. I agree. The way this is handled at the moment is dangerous to the point of this not being worth it at all.

> it can by using `git update-index --test-untracked-cache` but it takes a long time to check this

How about just writing a file to a scratch directory, and see if the mtime of the directory was changed?

considering that they have actual test code which also takes quite a while to run, I would assume that there are systems misbehaving in many different ways, all of which might cause this feature to break, so all of them needs to be tested against.

The check you're talking about is one of the many checks it does, but there was further breakage which all needs to be checked against.

or how about just turning it on automatically for known-supporting systems, and leaving it as a system-wide config option for unknown systems?

The underlying file system determines compatibility so there is no OS level switch to check.

Seems like a flaw in POSIX -- there should be a bit in statfs (?) for something like this.

There is in struct statfs, which can be obtained for an open file descriptor using the fstatfs(2) system call, if you (a) want to make this autodetection OS-specific (statfs is Linux-specific, but I'm sure there's equivalents on other OSs) and (b) maintain your own list of compatible file system types.

I can't think of real world use cases that make sense to me, but I would guess they are worried about having mount points in the directory tree to check for modified files.

If so, they have to check every directory in the tree (or, alternatively, figure out all mount points in a different way, but I don't know whether that can be done efficiently in a portable way)

> It would be a pity if an ignorant user copied a repository to another filesystem only to find out that certain operations suddenly break.

Once tested (or enabled without testing if you know what you're doing), the location of the repository and uname are recorded. If you copy the repository elsewhere, git should detect and disable the cache.

Which one does that?

On which one does it work? I haven't run across a Linux filesystem where it doesn't work, including mounts over NFS. But I suppose on some non-POSIX platforms you might have more issues, or with some esoteric mount options to screw with mtime or something.

The reason it's disabled by default is first of all that it's relatively new, but secondly that if your FS stops behaving as expected (or you move your repo to one that doesn't behave) it'll degrade very badly, i.e. "git status" might now completely miss files that have been modified in your working tree.

But if you're just running a system where you know you can trust the FS you can use the untracked cache and get a lot of "git status" speed-up, which'll matter more the larger your checkout size is in terms of checked out directories & files.

Looks like parallel's shared filesystem (linux guest, osx host) fails the test:

    % ~/g/git/git-update-index --test-untracked-cache
    Testing mtime in '/media/psf/Home/Downloads/junk' .
    directory stat info does not change after adding a new file

Reply on news.ycombinator.com