splitting git commits [LWN.net]

splitting git commits

Posted Feb 12, 2026 0:31 UTC (Thu) by AdamW (subscriber, #48457)
Parent article: Evolving Git for the next decade

"He discussed the workflow for splitting a Git commit, which involves seven separate commands with Git's current UI. Most users do not know how to do this, he said."

Sure I know how to do it!

cp bigfilewithlotsofchanges.py /tmp
git reset --hard
git checkout -b letstrythatagain
gedit bigfilewithlotsofchanges.py /tmp/bigfilewithlotsofchanges.py
copy/paste chunk
git commit -a -s
copy/paste chunk 2
git commit -a -s
rinse, repeat

what do you mean, that's not the right way?! Crazy talk.

to post comments

splitting git commits

Posted Feb 12, 2026 13:30 UTC (Thu) by alx.manpages (subscriber, #145117) [Link] (2 responses)

> git checkout -b letstrythatagain

These days, 'git switch -c letstrythatagain' seems to be preferred, I think.

> cp bigfilewithlotsofchanges.py /tmp
> git reset --hard

I would do it differently. I'd first commit to a throw-away branch, so that I can then cherry-pick from it.

Also, most often, 'git add -p' (and then 's' for split) would allow committing the changes separately without needing that dance.

It's only when the changes are too close together that you'll need such a dance.
And when you need it, I'd do it as:

$ git add bigfilewithlotsofchanges.py
$ git commit -m "WIP; let's split this"
$ git tag tmp
$ git switch -c tryagain
$ git reset HEAD^ --h
## loop:
$ git checkout tmp -- bigfilewithlotsofchanges.py
$ git restore --staged .
$ vi bigfilewithlotsofchanges.py ## select the parts you want to keep for this commit
$ git add .
$ git commit -m "part 1"
## goto loop or finish.
## now we've finished, make sure that we're exactly like we started:
$ git diff tmp
$ git tag -d tmp

It's a long procedure, but that gives us a lot of control.

splitting git commits

Posted Feb 12, 2026 17:47 UTC (Thu) by josh (subscriber, #17465) [Link] (1 responses)

> These days, 'git switch -c letstrythatagain' seems to be preferred, I think.

I genuinely find that confusing. `git checkout branchname` makes sense to me as the mechanism for "I want to check out this branch", and adding an option to create the branch makes sense to me as well. I could imagine wanting to change the option from `-b` to `-c`, but I personally feel like "switch" is not any clearer than "checkout".

splitting git commits

Posted Feb 12, 2026 17:58 UTC (Thu) by alx.manpages (subscriber, #145117) [Link]

The problem with git-checkout(1) is that it has too much functionality, and thus is somewhat dangerous.

That's why they split its functionality into separate commands git-switch(1) and git-restore(1).

See <https://git.kernel.org/pub/scm/git/git.git/tree/Documenta...>.

At first, I was a bit confused, but I'm now accustomed to git-switch(1), and it feels natural.

splitting git commits

Posted Feb 12, 2026 14:11 UTC (Thu) by iabervon (subscriber, #722) [Link]

That is... a... way. I'm not sure there is a right way, though, just different ways that different people do use successfully. My personal method is actually for taking a branch that has a bunch of commits with mistakes I fix later, accidental whitespace changes, parts of false starts, etc. and making a clean branch where each commit does things I can describe and justify and eventually reaches almost the same tree.

git checkout origin -b refine
git diff HEAD messy | git apply
(edit, sometimes)
git add -p (say yes to what you want to do in this step)
git checkout .
make check
git commit
(repeat)

There are some snags around handling new files that "messy" added, but it's otherwise a pretty nice workflow (and fewer than seven git commands?). On the other hand, I've never taught someone else to do it, so I don't know how easy it is to learn.

splitting git commits

Posted Feb 12, 2026 16:00 UTC (Thu) by easwarh (subscriber, #131924) [Link]

In case you weren't joking, git add --interactive is your friend