3 ms·

There is the ~ or ^ suffix to select a parentage. Also, vin-fugitive selects the parent automatically when you say "rebase starting here" on a commit under the

There is the ~ or ^ suffix to select a parentage. Also, vin-fugitive selects the parent automatically when you say "rebase starting here" on a commit under the cursor. Not sure what it does for merge commits; there's so great default there.

woojoo666 4y ago
You still have to go through the "pick"/"reword" flow though. Most of the time people just want to modify a single commit. So why not just have a command for it, instead of needlessly exposing the low-level rebase process to the users
- shikoba 4y ago
  git commit --amend Or git rebase It's two simple command
  - woojoo666 4y ago
    Git commit amend only works if you want to modify thr latest commit. Rebase is unnecessarily complicated if you just want to modify a single commit. It should be something more like `git edit [commit sha]`
    - mathstuf 4y ago
      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

You still have to go through the "pick"/"reword" flow though. Most of the time people just want to modify a single commit. So why not just have a command for it, instead of needlessly exposing the low-level rebase process to the users

shikoba 4y ago
git commit --amend Or git rebase It's two simple command
- woojoo666 4y ago
  Git commit amend only works if you want to modify thr latest commit. Rebase is unnecessarily complicated if you just want to modify a single commit. It should be something more like `git edit [commit sha]`
  - mathstuf 4y ago
    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.