4 ms·

That gets complicated. What if there's a merge commit between here and there? How about a conflict? You cannot hide the underlying mechanism of reapplying a set

That gets complicated. What if there's a merge commit between here and there? How about a conflict? You cannot hide the underlying mechanism of reapplying a set of changes. On that note, I have written something like this, but it is not something I think belongs in the standard toolbox. It is a tool that applies "formatting" fixes to a topic, preserving history topology. However, it requires some automated tool to be able to perform the edit so that any conflicts can be resolved by running the tool to perform the edit (typically clang-format or autopep8, but sed or something like that is also a candidate). I don't know that requiring your edit to be expressed in terms of sed is suitable for such a "simple" tool to replace rebase.

woojoo666 4y ago
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.
- mathstuf 4y ago
  I, on the other hand, do something similar, but run into conflicts all the time. Usually when reordering commits or fixing up missed hunks that belong in some older patch. I do conflict resolution dozens of times a week. I guess we just disagree on how shallow or deep any problems `git edit` tries to hide are in practice and therefore how much convenience it actually saves.

woojoo666 4y ago

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.

mathstuf 4y ago
I, on the other hand, do something similar, but run into conflicts all the time. Usually when reordering commits or fixing up missed hunks that belong in some older patch. I do conflict resolution dozens of times a week. I guess we just disagree on how shallow or deep any problems `git edit` tries to hide are in practice and therefore how much convenience it actually saves.