It would still use rebase in the background. If there's a conflict that happens when reapplying changes, then an error pops up, and the user can look into it an

It would still use rebase in the background. If there's a conflict that happens when reapplying changes, then an error pops up, and the user can look into it and will start to understand the process. But in my experience of just doing quick patches on my private repos (where I do multiple small commits a day so patching an earlier commit is relatively common), a conflict rarely ever happens. I think I've run into it once in my many years of dev. So for the majority of users, they wouldn't have to even know about rebase until they have quite a bit of experience with git (and programming in general). It's a better learning curve, especially considering Git is now being taught to beginner programmers. A `git edit` command is not as powerful as `git rebase`, but this is just how UX works. You expose a smaller simpler set of features at the front, and then (if you aren't Apple) allow the users to do more advanced low-level operations if they need to.