Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Splitting a Git Commit

blog.gnoack.org

Post reply on HN
Print view View original

21–30 of 74 posts

Re: Splitting a Git Commit

#21

Post by opello »

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.

Re: Splitting a Git Commit

#22

Post by jatora »

hungryhobbit wrote: post #20
BeetleB wrote: post #14

Earlier quoted context omitted.

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.

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

The rise of AI and the death of SO is a beautiful beautiful thing. That community is the worst, and this opinion seems to be shared universally by anyone who had extensive interaction with it.

Re: Splitting a Git Commit

#23

Post by adregan »

diath wrote: post #9

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.

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.

Re: Splitting a Git Commit

#25

Post by qsera »

merb wrote: post #19
qsera wrote: post #17

Earlier quoted context omitted.

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

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)

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

I use this only for the aforementioned purpose.

Re: Splitting a Git Commit

#26

Post by sunshowers »

jaltekruse wrote: post #6
furkanturan wrote: post #2

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.

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'…

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

Re: Splitting a Git Commit

#27

Post by bonzini »

svyatoslavpavl wrote: post #8

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

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.

Re: Splitting a Git Commit

#29

Post by wasting_time »

svyatoslavpavl wrote: post #8

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

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

Post reply on HN