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.
Splitting a Git Commit
71–74 of 74 posts
Re: Splitting a Git Commit
#72Re: Splitting a Git Commit
#73Earlier quoted context omitted.
These answers are ~15 years apart, so the vote difference is not surprising. I personally sort by ‘date modified (newest first)’ on StackExchange sites.
> I personally sort by ‘date modified (newest first)’ on StackExchange sites. Sites such as stack overflow would improve significantly if they actively tagged questions and answers with version numbers they would be applicable to.
Re: Splitting a Git Commit
#74Earlier quoted context omitted.
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.
AI could gorge itself once on (probably stolen) training data from SO, among others, but who will answer new questions now, and where will new training data come from?
This is clearly not the case. You can make up your own programming language and feed it to an LLM and it can reason and answer questions on it.