Re: Committing crimes with NTFS-3G

From: Torsten Bögershausen <tboegi@web.de>
Date: Sep 5, 2024, 19:51 UTC
Message-ID: <20240905195139.GA9644@tb-raspi4>
In-Reply-To: <8a8a7f75-6a2f-4fd9-b3cf-df61129a355a@gaijin.team>

On Tue, Sep 03, 2024 at 08:30:16PM +0300, Roman Sandu wrote:

Side note: Please avoid top-posting here in this list

> .gitattributes is this
> https://github.com/GaijinEntertainment/DagorEngine/blob/main/.gitattributes
> `core.autocrlf` is unset.

That is according to the book, good.

Show 6 quoted lines

>
> core.filemode is false.
>
> `git ls-files --debug` is extremely useful and I am a tiny bit salty that no
> one suggested it before I spent time learning how to parse the index file in
> C =)

No well, I read this as "thanks for the hint"

> But alas, nothing new, see my previous messages (hopefully they are visible
> to you, I am kind of new to mailing lists).

Yes, everything is here.

Show 5 quoted lines

>
> `git ls-files --eol` says that worktree uses crlf (which is expected, I
> checked out the repo under windows), while the index uses lf. Can that be
> the reason for Linux git thinking that the index is always out of date?
> Various dev tools work perfectly fine with crlf'd files on Linux.

Yes, that is not the problem for any performance issues.

I did set up a test, kind of. Exporting a git repo from a Linux NAS to a MacOs laptop, using Samba, and WLAN. A simple `git status` takes 4 seconds for 1800 files. The thing is that Git needs to lstat() each and every file, to find out if it has been changed. And if that lstat() call is slow, then `git status` will be slow.

I don't know, if the fs monitor works for your setup ?

https://git-scm.com/docs/git-fsmonitor--daemon

[snip]