Re: Stat cache in .git/index hinders syncing of repositories

From: Christoph Groth <christoph@grothesque.org>
Date: Jan 18, 2020, 22:04 UTC
Message-ID: <87d0bgs9o4.fsf@drac>
In-Reply-To: <20200118194204.GC6570@camp.crustytoothpaste.net>

brian m. carlson wrote:

Show 9 quoted lines

> On 2020-01-18 at 19:06:21, Christoph Groth wrote:
> > But if the above is not feasible for some reason, would it be
> > possible to provide a switch for disabling stat caching
> > optimization?
>
> Git is going to perform really terribly on repositories of any size if
> you disable stat caching, so we're not very likely to implement such
> a feature.  Even if we did implement it, you probably wouldn't want to
> use it.

OK, I see. But please consider (one day) to split up the index file to separate the local stat cache from the globally valid data.

(By the way, even after 12 years of using Git intensely I am confused about what actually is the index. I believed that it is the "staging area", like in "git-add - Add file contents to the index". But then the .git/index file reflects all the tracked files, and not just staged ones. This usage is also reflected by the command "git update-index".)

> However, there are the core.checkStat and core.trustctime options
> which can control which information is used in the stat caching.  You
> can restrict it to the whole second part of mtime and the file size if
> you want.  See git-config(1) for more details.

Thanks a lot, that did the trick! I’ve been already syncing mtimes. Setting both core.checkStat and core.trustctime to the "weak" values made the spurious modifications go away.

Still, this is a workaround, and the price is reduced robustness of file modification detection. Technically, that wouldn’t be necessary... I hope that in practice it won’t matter.

Show 6 quoted lines

> One final word of caution: you probably want to activate your sync
> tool only manually and only when the repository is idle.  Tools like
> Dropbox that automatically sync files one by one have been known to
> corrupt repositories because the way they sync data leaves the
> repository in an inconsistent state and doesn't honor standard POSIX
> file system semantics which Git relies on for integrity.

Yes, that’s why I still prefer Unison to more automatic real-time tools.