Splitting a Git Commit

ssigna11 3 days ago 29 commentsRead Article on blog.gnoack.org

ES version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

83% Positive

Analyzed from 874 words in the discussion.

Discussion (29 Comments)Read Original on HackerNews

opello•21 minutes ago

It seems strangely polarizing to refer to the "old and cumbersome" interactive rebase approach in contrast to "the right approach" using `git history` which is a brand new, experimental feature as of Git 2.54 from April 20, 2026, a few months ago.

I have split a lot of work with interactive rebasing. I'm excited to try `git history split` and to have learned about it here. But the stylistic flourish makes it seem like it's been a feature for years that people just haven't moved to instead of being something shiny and new to be excited about trying.

roelschroeven•about 2 hours ago

> P.S. The stack overflow question for splitting commits discusses the old and cumbersome approach. The 20th answer discusses the right approach but has a meagre 2 upvotes as of today, compared to 2656 for the older top answer with the cumbersome approach.

It now has 5 upvotes. A long way to go to 2656 but at least it's going in the right direction.

hotelsacher•about 2 hours ago

Still, it shows how incredibly broken the StackOverflow system is. It's completely normal for older answers to become outdated, but they still act like the old answers are laws of nature.

BeetleB•about 1 hour ago

I think this is harsh criticism. It's because not many people use SO any more.

One of SO's selling points was that outdated answers get replaced with the more modern, better ones - and it worked for many, many years.

hungryhobbit•35 minutes ago

... until they decided it was a good idea to train all power users to grief new users off the site.

layer8•about 1 hour ago

At least the answer is there. When asking ChatGPT (Plus) the same question, it only suggests the old ways.

no-name-here•about 1 hour ago

It’s now the 6th answer instead of the 20th, and if answers are sorted by Trending (which I recommend people do) in the dropdown, it’s currently 3rd.

mateusz834•14 minutes ago

or use jj and stop worrying about git

jj split --interactive {ref}

BeetleB•5 minutes ago

You don't need --interactive. It is interactive by default.

pixl97•8 minutes ago

Ah yes, I'll just pass that over to the compliance team and wait a few months for a denial.

BeetleB•4 minutes ago

You need compliance to install jj?

ivanjermakov•about 2 hours ago

StackOverflow is really not great at handling questions for which the right answer changes over time. I guess it doesn't matter since SO is dead anyway: https://news.ycombinator.com/item?id=46482345

diath•about 2 hours 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.

adregan•15 minutes 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.

qsera•about 1 hour ago

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

merb•about 1 hour 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•13 minutes ago

https://git-scm.com/docs/git-gui

I use this only for the aforementioned purpose.

matheusmoreira•about 2 hours ago

Today I learned about git history split. Thanks!!

ajasmin•about 2 hours ago

Love the minimalist blog layout

BeetleB•about 1 hour ago

Is this yet another case of git improving its UI due to jujutsu?

(This is exactly how jj does it.)

If you like this kind of convenient CLI command, I would seriously recommend giving jj a try. To give you an idea, I never bothered splitting a commit in my git days. I do it almost daily with jj. Lots of other niceties that I didn't bother with in git, but routinely do in jj.

jj has fewer commands than git, yet does everything git does.

furkanturan•3 days ago

I never thought about whether this was possible, but now that I know it is, I immediately see how useful it could be for my workflow.

jaltekruse•about 2 hours ago

I had a team that insisted on a linear history and was constantly rebasing things. This workflow strongly favors "just squash it all together" before a rebase to avoid re-resolving the same conflicts. This workflow often produces big patches that reviewers end up asking to be broken back up. This experience and a recommendation from my manager at the time made a good git GUI like sourcetree a daily driver for me. It's just second nature to review my own changes every time I stage files and quickly do a mix of staging whole files or "hunk-based", even allowing clicking to select specific lines within a hunk intuitively, rather than using the terminal UI and asking git to take a guess at splitting a hunk. I find a good git GUI invaluable, I have used sourcetree for years and love it. Unfortunately sourcetree isn't available for Linux, but I recently found SourceGit which seems to be a decent substitute.

Highly recommend trying a good GUI out, I think you would likely have similar ah-ha moments about workflow optimizations, and honestly I just cannot understand how people get by in git without a convenient way to visualize the commit tree (and yeah I know there is a decent command line treeview, but the context switching all the time in the terminal to go from viewing the tree or even the simple log to exit out and ask for commit contents just is so much more fussy and tedious).

sunshowers•9 minutes ago

BTW not sure how you feel about LLMs but merge conflicts are not really an issue with them any more.

farlight•about 2 hours ago

git rerere will resolve repeated conflicts for you automatically, you just need to enable it.

https://git-scm.com/docs/git-rerere

esafak•about 2 hours ago

https://github.com/DetachHead/rebased

svyatoslavpavl•about 2 hours ago

The bit that made this click for me: it works on any commit in history, not just HEAD. Mark the commit as edit in git rebase -i, then git reset HEAD^ to uncommit it while keeping the changes in the working tree, and rebuild the pieces from there.

git add -p is the real workhorse for the rebuild: s splits a hunk into smaller ones, and e lets you hand-edit the hunk when the boundary doesn't fall on clean line breaks. Stage a coherent slice, git commit, repeat until the tree is empty, then git rebase --continue. The rebase's only job is to drop you at the right spot; add -p does the actual splitting.

wasting_time•6 minutes ago

Please don't use LLM to write HN comments. To quote the guidelines[0], "HN is for conversation between humans".

[0] https://news.ycombinator.com/newsguidelines.html

bonzini•9 minutes ago

Or the opposite direction, with repeated "git checkout -p ..." and commit steps. Slightly less comfortable because you have to figure out (such as from "git rebase --edit-todo") the later commit, but it makes testing the pieces easier.