For the former you want flexible history, distributed repos and freedom to do whatever you want.
For the latter the history should be sacrosanct and the repository is better be more or less centralized.
git tries to sit on both chairs and therefore has to adapt a quite awkward position.
I also don’t understand your larger point about git and what the problem is. For almost everyone using git, the pushed history is sacrosanct, and the main repo is centralized. The main workflow for rebase is to clean up before making commits public.
"Version control" is a log. I should be able to return to any point in history at any time. I should not be able to destroy this history no matter what I do. The history should be backed up in a remote location.
With git every once in a while these two come into conflict: I'm using my branch as a change management system and then someone else pulls that branch and makes a couple of changes on it. Then I force push and the mess begins.
Regarding centralized repository: say, I have two working copies. In goode olde subversion there was the "master" version in trunk and two local versions, one per working copy. Three versions altogether. Pretty clear which is which.
Now in git I have:
- master in origin repo
- origin/master in wc1
- master in wc1
- actual file in wc1
- all the same in wc2
Seven potentially different versions of the same exact file. That's even without mentioning a stash.
> Then I force push and the mess begins.
That is your problem right there. Force pushing over published history should always be avoided. Don't do that, it is very unfriendly to others you work with. Just always pull, resolve any conflicts, then push your changes without forcing them. If you need to force in order to fix a serious mistake, then notify everyone first and have people hold their changes, then pull everything, resolve the problem, force push, and notify everyone again to "force pull" by first fetching, then reset their branch to what's in the origin verison; using reset --hard will let them avoid having any conflicts after you force pushed. Consider carefully whether the mistake even warrants a force push, or if you can make do with new commits on top that fix the bad ones.
> Regarding centralized repository [...] Seven potentially different versions of the same exact file.
You're conflating multiple different topics. The existence of multiple copies of a file isn't related to which repo is the central one, nor is it some kind of problem.
The origin repo is your central repo. Your downstream repo has to copy from the upstream/central repo if you even want to work on the code. What you called "copies" in origin/master and master are branches, not copies of the file. The only single copy on your machine from your point of view is your local workspace, which expanded from your "master". stash is something that happens behind the scenes to your git database, it's not making more working copies. wc2 is another repo or computer, it's not even relevant. None of these copies you're talking about are visible to a user except the one working copy.
That is my problem right here.
There is no way to tell the difference between "I push to make something public" and "I push to back up my data in some safe location".
That said, making backup data in a safe location isn't what git was really made for. If you really don't want history to be there, you can use cp or rsync, or you can git clone -depth 0 from the backup machine, or just use backup software. There's "bup" which is a backup tool based on git...
I don’t think the argument is that the difficulty is a virtue, nobody is trying to be snobby, so try to avoid jumping to that conclusion.
Git just has some inherent complexity. Git does have a steep learning curve that is the root of a UX problem. But it’s not clear what better abstractions there are or how to simplify git. Lots of people have tried to make a higher level porcelain, and the issue isn’t going away. You are welcome to suggest & create a git wrapper that makes it simpler and less dangerous.
Perforce is easier to learn, so you might try using that instead. I use both and I’m becoming more and more frustrated with Perforce because git is so much more flexible and safer and easier to use once you learn how to use git.