Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I’m doing rebasing a lot these days, especially since I started using gh stack. The main struggle I have with rebasing is for git to recognize that a branch has actually been merged when its commits have changed (e.g., if I forgot to delete the local branch with old commits and come back months later and trying to figure out if it was actually merged or not). My understanding is that this is nicer with jj when you work locally, but if you sync with GitHub, I think your still faced with the same problem, or?
What are people doing to workaround this? I’ve tried to ask LLMs, but the complexity is frankly a bit off putting (I don’t have the suggestions handy)
by meling - Don’t you have an id system, like an issue tracker? That’s your source of truth for change requests.
The common advice is to never have long standing branches for WIP. But if you do, squash it to have a small number of commits, then replay it on top of the default branch. The try to understand why there’s any diff or conflict (refactor, update to the design, code removal, was not merged at all,…). As I squash merge, I always remove the PR branch from the main repo. And I keep it for about a week on my local repo (In case the PR is reverted and I needed my drafting version of it).
by skydhash - Today I learned about git history split. Thanks!!
- 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.by furkanturan
- 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).
by jaltekruse - The SO upvote problem is real. Once an answer hits a few hundred votes, nobody scrolls past it to check if something better came along.by bywater
- I think I'd rather keep my old school interactive rebase skills sharp for when I actually need it
- Yes I prefer to keep using the much more general rebase interface instead of memorizing more verbs for very specific tasks.by account42
- 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=46482345by ivanjermakov
- > StackOverflow is really not great at handling questions for which the right answer changes over time.
The right answer doesn't change over time. It can vary with the release version you are targeting.
- In case you're curious if _you_ can run `git history split`, the answer is almost certainly no, unless you manually installed the newest release of Git within the last 3 months.
`git history` was introduced as an experimental command less than 4 months ago, which means that there are essentially zero OS releases that packages a version that contains it by default. Also, if you're on OSX and run `brew install git`, it will not overwrite the Apple version that is too old to have it.
Git 2.54 was the first release with this subcommand and it is not in Xcode CLT, Debian testing, Ubuntu 26.04 - nothing. It will be "normal" in a year, but it's ridiculous to criticize SO for "old" methods of splitting long before anyone ships with it.
by schacon - It's in Fedora, Arch, and many other popular operating systems.by nemetroid
- Point taken, that's true. I'm admittedly developing on distributions where the updates are faster, so I missed that. But then again, I also didn't expect that this short weblog article would have such a large audience when I wrote it. :)by gnoack
- or use jj and stop worrying about git
jj split --interactive {ref}
by mateusz834 - Ah yes, I'll just pass that over to the compliance team and wait a few months for a denial.by pixl97
- This. Can't imagine going back to git after getting comfortable with jj, it's excellent.by cleaning
- You don't need --interactive. It is interactive by default.by BeetleB
- This is a relatively recent feature. I was first introduced to it in GitHub's release notes for Git 2.54:
https://github.blog/open-source/git/highlights-from-git-2-54...
And discussion at the time:
by jez - 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.by diath
- I do the same, but use `git gui` to select the changes.by qsera
- 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:
- `git rebase --continue`- (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`.
by WorldMaker - 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.
by adregan - > 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.
by brewmarche - 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.by no-name-here
- 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.by hotelsacher
- 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.
by opello - 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.