I get where the author is coming from, but personally I feel like the juice isn't worth the squeeze. The thing about git is that it is incredibly powerful, and the model is very simple and well thought out. The only problem is the CLI is full of warts. That sucks for beginners, but once you get over the hump, git is like a chef's knife—you can do anything with it, quickly and efficiently. So any layers you build on it will, at best, make it easier to learn, but they won't make it more powerful. On the downside, making a legible UI will require some opinionated decisions about what to emphasize and what to de-emphasize (sort of like how Mercurial is designed in a way that discourages rebasing).
As to the specific suggestions, some of them are very poorly thought out. For instance, the proposal for `git reword` suggests you shouldn't need to have the commit checked out since it won't create a merge conflict. Sure, but the SHA will change, and this will change all downstream commits, which means you could potentially be triggering a massive, silent rebase that will blow up spectacularly when you try to push.
Another one is the `git preview`, saying you should be able to predict the conflicts on a rebase. But this is exactly what rebase does already! You start rebasing, then you get a conflict, at that point you can either fix it and proceed or abort the rebase being no worse for wear. Obviously you can't see the subsequent conflicts until you resolve the first, so there's no magic "see all downstream conflicts for the entire operation" possible (if that's what the OA meant, I'm not sure).
Finally, the `git undo` is just a hand-wavy ask for the functionality provided by `git reset`. Combined with `git reflog` you can undo arbitrary operations including ones that you had abandoned and "overwritten". It's an incredibly simple and powerful model. I get that the `git reset` flags are not super intuitive, but they are few, terse, and domain complete.
>That sucks for beginners, but once you get over the hump, git is like a chef's knife
When do you get over the hump? I've been using git for nearly a decade, I understand the internals of its data structures, I can talk about the difference between a rebase and a merge, and I still need to reference a cheat sheet for anything more complex than creating a branch, pulling from head, and committing.
What really helped me was to create aliases and short scripts for the variety of commands that I used. For example, I created a small script called `git-back` that is `git reset --soft HEAD^1`. The `git-back` takes a parameter for how many commits back you want to go.
Not sure if this is what everyone wants, but adding a wrapper language around the commands was really powerful for me. Everything could be tab completed, used names and terms that I could remember, and at times the new commands became so baked into my mind I forget at times they are not part of core git.
On the contrary: I myself have implemented these better operations, and they work great. They also exist in some other VCSes, such as Mercurial and Jujutsu. You can see the `git-branchless` column in the table for comparison with the other clients.
Apologies, but I misunderstood what you meant by the "downstream" conflict situation. That's not possible in git-branchless, but it is possible in Jujutsu, since it stores conflicts as first-class objects, so it can actually proceed with the application of subsequent patches even if a previous patch conflicted.
`git rebase` can be started and aborted, but to start it safely, you have to first set aside all of your existing work in the working copy. You can't really run it on the background or in parallel, which makes it annoying to do operations like rebase all branches, and can ruin build caches, which ends up being a significant problem on larger repositories. It's possible for the UI to show an icon next to each of my branches indicating whether they would rebase onto the main branch successfully, but no interfaces at present do (including my own). Or, for example, I should be able to start dragging a branch to indicate a rebase, and the UI should speculatively check which target branches can be rebased onto successfully and indicate that.
As to the specific suggestions, some of them are very poorly thought out. For instance, the proposal for `git reword` suggests you shouldn't need to have the commit checked out since it won't create a merge conflict. Sure, but the SHA will change, and this will change all downstream commits, which means you could potentially be triggering a massive, silent rebase that will blow up spectacularly when you try to push.
Another one is the `git preview`, saying you should be able to predict the conflicts on a rebase. But this is exactly what rebase does already! You start rebasing, then you get a conflict, at that point you can either fix it and proceed or abort the rebase being no worse for wear. Obviously you can't see the subsequent conflicts until you resolve the first, so there's no magic "see all downstream conflicts for the entire operation" possible (if that's what the OA meant, I'm not sure).
Finally, the `git undo` is just a hand-wavy ask for the functionality provided by `git reset`. Combined with `git reflog` you can undo arbitrary operations including ones that you had abandoned and "overwritten". It's an incredibly simple and powerful model. I get that the `git reset` flags are not super intuitive, but they are few, terse, and domain complete.