Splitting a Git Commit
blog.gnoack.org
Splitting a Git Commit
1–10 of 74 posts
Re: Splitting a Git Commit
#2I 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.
Re: Splitting a Git Commit
#3StackOverflow 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
Re: Splitting a Git Commit
#4> 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.
Re: Splitting a Git Commit
#5> 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.
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.
Re: Splitting a Git Commit
#6I 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'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).
Re: Splitting a Git Commit
#7I 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'…
Re: Splitting a Git Commit
#8The 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.
Re: Splitting a Git Commit
#9That'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.
Re: Splitting a Git Commit
#10I 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'…
git rerere will resolve repeated conflicts for you automatically, you just need to enable it.