brian m. carlson wrote:
> 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.

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