Git is designed for the case where you have multiple remotes with no central authority. Except that’s not how any project I’ve _ever_ worked on functions in reality. It makes sense for some applications, but if I say that I run Linux, there’s an assumption that I’m running something compiled from https://github.com/torvalds/linux - I.e. there is a central space.
I’ve used git and perforce in anger for a decade, in teams of 1 to 150+ (with a brief blip in the middle where I tried plasticscm which was a mistake), and I’ve been the “git guy” on teams during that time. If git’s defaults were tweaked for “one origin, probably authoritative” and it had better authentication support out of the box it would be a significantly better experience for 99% of people. Those 1% of people who are left over are going to customise their config anyway, so make them add the distributed-defaults=true flag and the rest of us can get on with our work.
I do deal with multiple remotes quite often and haven't encountered issues. You're right about submodules, I avoid setting up projects with them, even at the expense of more manual work or complicated automation.
I'm definitely not using it as a substitute for rsync - I do prefer to put rules in place to avoid editing (shared) history, for obvious reasons.
Here are some examples:
We have some repositories that are created and maintaned by scripts, mostly for CI purposes. The scripts have to deal with various aspects of how checkouts, commits, automatic rebases etc. are done. For example, I had to write a script that automates "git-rebase -i" (simulating the editor, parsing the contents of the file that git generates in order to configure the rebase etc.)
Another example: generating various statistics for the repository (again, automatically). This is something we used to do to analyze the situation with build servers: how many do we need, how to load-balance them etc.
Another example: automated builds, where the build system needs to integrate with Git, extracting necessary info, rebasing, committing, parsing commit messages for guidance etc.
> rsync
What I mean by this is that most programmers use Git as an append-only database. And, by and large, aren't bothered by the state of the history, never utilize the history for anything. As long as they are all able to access the source code in some sort of sane state, they are fine.
This creates a lot of problems for the automation / infra / release people because they want history to have certain properties, which are lost if it's treated as append-only log, but usually our pleas are ignored if they are even heard.
Though I have to say, for your examples (generating statistics and automated builds), read-only operations generally suffice for me, aside from pushing tags. I prefer to implement pull-based deployment if possible, and only allow release branches to fast-forward.
At least, this is what it looks like from your own description. This is, probably, what most people do with it most of the time. And the weird corners will be found when they need to automate things, or when they want to deal with modular repositories, or history rewrites. These aren't everyday tasks / not for everyone on the team, but, these things do happen, especially in smaller teams, where there's no dedicated infra person or group these can be delegated to.