or use jj and stop worrying about git jj split --interactive {ref}
Ah yes, I'll just pass that over to the compliance team and wait a few months for a denial.
You need compliance to install jj?
Splitting a Git Commit
31–40 of 74 posts
Re: Splitting a Git Commit
#32Earlier 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.
It was always like that.
It's due in part to the number of people that kept posting screenshots of their code in their question, and the number of people that couldn't search to save their life. The noise ratio on incoming questions was always ridiculous, and the number of people who don't know how to ask a technical question is staggering. I do wish they had started to ask a series of questions to people for their first 5 or 10 posts to force them to ask questions in a useful way that was conducive to getting answers. The whole site never got over being hostile to new users.
SO had a number of fundamental issues. If you found a duplicate and flagged it as such, you couldn't explain why you thought it was a dupe in the flag. This meant that "this is a different question but the answer is the same" was just tagged a dupe the same way "this is literally the identical question" was.
I stopped participating entirely after a single event. When I was moderating the moderation, and the site decided to give me a trick question to "test if I was paying attention". Yeah, no. I don't have time for that bullshit. Apparently I'm still a top 1% user, though, and I think I've gained another 8,000 or 9,000 points since I left and stopped answering at anything.
Re: Splitting a Git Commit
#33> 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.
These answers are ~15 years apart, so the vote difference is not surprising.
I personally sort by ‘date modified (newest first)’ on StackExchange sites.
Re: Splitting a Git Commit
#34Is 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 ev…
My understanding is that `git history` was started after seeing jj, yes. I don't have a citation for you though, I could be wrong, that's just what I remember.
Re: Splitting a Git Commit
#35It 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 lik…
I agree, interactive rebasing existed for ages and git history is mainly a user experience improvement over it. This way of framing git history goes way past engagement tricks and erodes the blogger's credibility.
Re: Splitting a Git Commit
#36Is 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 ev…
Yes this is how jj does it, except that jj is more powerful because it does automatic rebase of all the downstream commits.
If you have any descendants of the gir history split (i.e. it's not the most recent) you'll have to do some more work (a rebase) to get back to a useful history. I think you can do this in the middle of an interactive rebase which is ok, but still not as easy.
Re: Splitting a Git Commit
#37Earlier quoted context omitted.
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.
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.
> One of SO's selling points was that outdated answers get replaced with the more modern (...)
I don't think this is description is right. What you describe as "outdated answers" are actually answers to apply up to specific releases. Just because a project launches a release that rolls out a new feature that doesn't render the old answers wrong or stale.
Re: Splitting a Git Commit
#38Earlier quoted context omitted.
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.
At least the answer is there. When asking ChatGPT (Plus) the same question, it only suggests the old ways.
> At least the answer is there. When asking ChatGPT (Plus) the same question, it only suggests the old ways.
The old ways are still the right answer for multiple reasons, such as they still clearly work with the latest release and odds are you and everyone around you is not running the latest and greatest version of git installed.
Re: Splitting a Git Commit
#39That'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.
It's not that roundabout compared to what `git history split` is doing. It's sort of the missing tool in a lot of the rebase discussions (in the Stack Overflow answers). Basically `git history split` is most useful for "split an older commit in this branch", so it's a higher level complex dance of, essentially:
- `git rebase -i`
- Change the TODO list to `edit` the chosen commit (everything else to `pick`)
- At the `edit` point:
- (simplified) `git add -p`
- `git commit`
- `git add -u`
- `git commit`
That "simplified" `git add -p` in the middle and that assumption that everything else not selected is the "other patch" is fine for quick splits, but there's still power user super powers in knowing the full rebase workflow and `git add -p`.
Re: Splitting a Git Commit
#40Earlier quoted context omitted.
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'…
git rerere will resolve repeated conflicts for you automatically, you just need to enable it. https://git-scm.com/docs/git-rerere
Be careful, it will also cache any mistakes in merging including things like bug regressions. Especially if you also have a git history full of cherry-picking and reverts.