Most real complaints about git are around scalability of giant monorepos, and a lot of work has gone into various solutions.
The secondary complaints about usability seem to be papered over by popularity, and of course the relevant xkcd: https://xkcd.com/1597/
For me, I'm excited about better, more rigorous merging and being able to cherry-pick & rollback changes without causing conflicts later on. (Cherry-pick in Git makes a new, unrelated commit, so merging with the branch you cherry-picked from can often cause merge conflicts, etc)
In general, tracking and working with actual dependence between patches seems to open up more workflows, and less hacky ones.
e.g. giant monorepos weren't a problem even for ancient centralized VCs because these were file based, and if you wanted to work on a part of the tree it didn't matter - just push and pull the part you care about. But git has a data structure that forces everything in a single tree, so you have to use hacks (submodules etc.).
Same thing for the much of the UX and the other complaints (changeset/patch model). When you get down to it, the data structure is behind 90% of difficulties with git.
This is due to the lack of a solid theory to match the intuition. The "git way" of trying to match each use case is to add a new command for each new use case.
I don't think you can fix "just the UX" without fixing the underlying algorithms.
To me, git's problem is the exact opposite - the commands are based on how the underlying technology works, not on the use case for the user.
The best example is 'reset'. I understand git's internals reasonably well so I know the reason why, but it's not obvious that you need the same command to "un-add" a file, or to wind history back two commits.
A talk introducing the issues with git and how gitless improves upon them https://www.youtube.com/watch?v=31XZYMjg93o
The patch model is simpler IMO
And Anu is apparently even sounder and faster?
https://pijul.org/manual/why_pijul.html#pijul-for-darcs-user...
git was built as a tool for completely distributed source versioning, but most of us are using it in a centralized way. It's nice to be able to work offline, but when we need to synhcronize there's always a huge dance of fetching first, see if it has moved, merge/rebase, etc... git is good at storing what we did, but it doesn't help at all at saving what we are _doing_: all changes to the working directory are ephemeral, like files stored in ramfs. When working on public repositories, you can't push a branch prefixed with your name; you have to fork the whole project _and_ push a branch before you can start interacting. Instead of having one server and a client, you now have 1 central server, 1 other server that only _you_ can access and will in practice contain 1 branch, and will be abandoned as soon as you're tired of it, and a client. Rights can't be managed at the branch level, so I'm just going to copy-paste the whole thing from the beginning of history and give it to you.
What I would like to see in a VCS:
- There is one central place where people coordinate - There is exactly one commit associated to a branch, and that association is the same on all machines at the same time (I don't want to git fetch) - If you want to do changes to a branch, you do a sub-branch - That sub-branch, along with your local changes in or out of the staging area, is synchronized to the server. If authorized, other clients can have a view of those as well
It seems it already exists with fossil (https://fossil-scm.org/home/doc/trunk/www/concepts.wiki#work...) and with older SCMs, although older SCMs are plagued with the locking problem.
In a way the work that is done to handle giant monorepos is helping git move in this direction: all branches are automatically synchronized, and the vision with this kind of repo is that it's ok to commit often, even in small batches. But it's not quite there yet. I've read an account of how things are done in Google (https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...) and it's closer to my dream system.
I believe this is more of a issue with GitHub then with git itself.
Still, it's not enough in my taste because I want all content to be synchronized everywhere