> `git reset` by itself doesn't split a commit AFAIK. You need to then `git add -p` and `git commit`
If you want to generate two commits with the exact same message, then do:
git checkout combined-commit
git reset --soft previous-version
git commit -C @
Do something with them. Put them in a commit, put them into a commit in the global stack of todo commits or tell git to do that automatically.
> Or if you want to split a commit that's not at HEAD?
Check it out or do a rebase.
Those were rhetorical questions. I know how to use Git. Sorry that I was unclear.
Git reset splits a single commit, into two "things", another commit with the first part and a second part that is put into a version prepared for a commit (--soft), prepared for further editing (--mixed) or thrown away (--hard). To me that counts as commit splitting, but it may not match with JJ terms. Also splitting into two commits with the same commit message doesn't sound quite useful to me, so the default of Git two require a second commit message is sensible to me.
> Those were rhetorical questions.
Ok, but then what was your point?
Correct me I'm I'm wrong but I think were talking about using `git reset HEAD^` for splitting a commit. That will move the current branch backwards one step. With `--mixed`, it will also move the index back one step, so the index is empty (relative to HEAD) and the working copy has the combination of changes that were in the previous HEAD commit and the working copy (relative to the previous HEAD). I think that's more like squashing than splitting because we have fewer "things" after: we have one commit fewer (the previous HEAD commit may of course still be reachable from another branch, in which case we still have the same number of "things" afterwards). It's similar with `--soft` and `--hard`, except that the old changes end up in a different "thing".
At a less technical level, the point of splitting a commit is to end up with some of the changes from one commit in a new commit and the rest of the changes in another commit. That's what meant when I said "`git reset` by itself doesn't split a commit", because you need to do something like this:
> Ok, but then what was your point?Just that additional steps are needed.
For example, if you wanted to split the HEAD commit but you had already started working on a new commit so have some changes in the working copy, then you might instead have to do something like this:
The other case I mentioned was if you want to split a commit on another branch. Then you have to insert some additional commands in that sequence. As I said, I know how to do this with Git. I just find it easier to do with jj, where it's `jj split -r xyz` to split commit xyz, whether it's the current working copy, an ancestor commit, or on an unrelated branch.(Take my Git commands with a grain of salt because I haven't used Git in 10 years.)