I'm not a very advanced Git user, so I wonder why that would be? Note that I was NOT using it as a remote repository but purely for backup purposes, meaning all changes were always mirrored to the server and that's it. Nextcloud still messed that up. So I don't know how that's a bad idea, considering sync of a large number of files is the single purpose of file sync.

> So I don't know how that's a bad idea, considering sync of a large number of files is the single purpose of file sync.

Yeah it is, but things aren't all rosy and still very flaky here and there (again, I'd wager it's similar for most other cloud sync clients). So we have to still work around these limitations.

I'm not very familiar with git internals, but git writes many files, most of them tiny. When I physically copy a directory with a git repo, the working directory (the currently checked out files) always copies over fast, but the potentially tens of thousands of tiny files take forever (they're not continuous and each one has to be seeked on disk, and each file has some overhead. The overhead isn't noticeable for large files, but adds up for numerous tiny ones).

Next to selfhosting Nextcloud, I also selfhost GitLab for that purpose. That is way overkill though. There's lightweight git servers like Gitea that I've heard people selfhost. If you don't rely on dumb file-based sync but only sync to your remote in git protocol, things won't go wrong anymore.