Rendered at 16:45:33 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
roelschroeven 1 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 1 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 31 minutes 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.
no-name-here 10 minutes 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.
ivanjermakov 1 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 55 minutes 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.
qsera 8 minutes ago [-]
I do the same, but use `git gui` to select the changes.
ajasmin 43 minutes ago [-]
Love the minimalist blog layout
matheusmoreira 50 minutes ago [-]
Today I learned about git history split. Thanks!!
BeetleB 33 minutes 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 1 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).
farlight 52 minutes ago [-]
git rerere will resolve repeated conflicts for you automatically, you just need to enable it.
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.
It now has 5 upvotes. A long way to go to 2656 but at least it's going in the right direction.
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.
(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.
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).
https://git-scm.com/docs/git-rerere
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.