4 ms·

That's good to know, I'd usually go about it in a roundabout way: soft reset the commit then git add --patch to stage the hunks to split it into multiple commit

by diath 1mo ago

That's good to know, I'd usually go about it in a roundabout way: soft reset the commit then git add --patch to stage the hunks to split it into multiple commits.

qsera 1mo ago
I do the same, but use `git gui` to select the changes.
- merb 1mo ago
  Which gui? I’m on Mac and somehow I could never really be happy with gui‘s for git. Gitkraken is the last I tried and I found it too much cluttering. Paid choices weren’t that great aswell either (yet)
  - qsera 1mo ago
    https://git-scm.com/docs/git-gui https://git-scm.com/docs/git-gui I use this only for the aforementioned purpose.
  - insane_dreamer 1mo ago
    try lazygit
- ericfrederich 1mo ago
  Yeah, I've been using git for nearly 20 years. I still rely on `git gui`. It's my crutch. I know you can do all of that in a terminal, but staging different hunks (or individual lines) is super easy.
adregan 1mo ago
I think you'll find your workflow is still required. `git history split` is really only focused on turning a commit into 2 commits, so if you wanted multiple, you would need to run the command multiple times. Add to that, it's patch functionality isn't as robust as `git add --patch`. For example, you cannot edit a hunk, so if you intended to tease out atomic changes, you won't be able to.
WorldMaker 1mo ago
It's not that roundabout compared to what `git history split` is doing. It's sort of the missing tool in a lot of the rebase discussions (in the Stack Overflow answers). Basically `git history split` is most useful for "split an older commit in this branch", so it's a higher level complex dance of, essentially: - `git rebase -i` - Change the TODO list to `edit` the chosen commit (everything else to `pick`) - At the `edit` point: - (simplified) `git add -p` - `git commit` - `git add -u` - `git commit` - `git rebase --continue` That "simplified" `git add -p` in the middle and that assumption that everything else not selected is the "other patch" is fine for quick splits, but there's still power user super powers in knowing the full rebase workflow and `git add -p`.
- opello 1mo ago
  This is nicely documented but seems to be missing the `git reset HEAD^` when rebase drops you into editing the marked commit.

by diath 1mo ago

That's good to know, I'd usually go about it in a roundabout way: soft reset the commit then git add --patch to stage the hunks to split it into multiple commits.

qsera 1mo ago

I do the same, but use `git gui` to select the changes.

merb 1mo ago
Which gui? I’m on Mac and somehow I could never really be happy with gui‘s for git. Gitkraken is the last I tried and I found it too much cluttering. Paid choices weren’t that great aswell either (yet)
- qsera 1mo ago
  https://git-scm.com/docs/git-gui https://git-scm.com/docs/git-gui I use this only for the aforementioned purpose.
- insane_dreamer 1mo ago
  try lazygit
ericfrederich 1mo ago
Yeah, I've been using git for nearly 20 years. I still rely on `git gui`. It's my crutch. I know you can do all of that in a terminal, but staging different hunks (or individual lines) is super easy.

adregan 1mo ago

I think you'll find your workflow is still required. `git history split` is really only focused on turning a commit into 2 commits, so if you wanted multiple, you would need to run the command multiple times. Add to that, it's patch functionality isn't as robust as `git add --patch`. For example, you cannot edit a hunk, so if you intended to tease out atomic changes, you won't be able to.

WorldMaker 1mo ago

It's not that roundabout compared to what `git history split` is doing. It's sort of the missing tool in a lot of the rebase discussions (in the Stack Overflow answers). Basically `git history split` is most useful for "split an older commit in this branch", so it's a higher level complex dance of, essentially: - `git rebase -i` - Change the TODO list to `edit` the chosen commit (everything else to `pick`) - At the `edit` point: - (simplified) `git add -p` - `git commit` - `git add -u` - `git commit` - `git rebase --continue` That "simplified" `git add -p` in the middle and that assumption that everything else not selected is the "other patch" is fine for quick splits, but there's still power user super powers in knowing the full rebase workflow and `git add -p`.

opello 1mo ago
This is nicely documented but seems to be missing the `git reset HEAD^` when rebase drops you into editing the marked commit.