|
|
Log in / Subscribe / Register

splitting git commits

splitting git commits

Posted Feb 12, 2026 13:30 UTC (Thu) by alx.manpages (subscriber, #145117)
In reply to: splitting git commits by AdamW
Parent article: Evolving Git for the next decade

> 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.


to post comments

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.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds