On the “git magic” side of things, if you have the same sort of OCD I have and wanted to split out the changes into separate commits, as long as each logical change was in a separate “hunk” (sections of code delimited by lines starting with @@), you can do:
-
Get a second branch with your code on it (so you’ve still got the original commits easily available if you make a mess):
git checkout -b mbox-haxx-take-2 -
“Uncommit” all your changes in all your commits:
git reset master(Specify something other than
masterif your branch was made from another base commit, or if you’ve pulled into master since making your branch; if you know how many commits you’ve made, you can useHEAD^^^^^where each^is one commit) -
Now if you run
git status, you should see thatmbox.rbis shown as having “Changes not staged for commit”. Excellent… -
Run
git add -p. This will present you with a single “hunk”, and ask if you wish to stage it for commit. When you sayyorn, it’ll go on to ask you about the next hunk, and the next, and so on. The plan here is to sayyto all hunks that are logically associated with each other, and saynto all other hunks. If you make a mistake, you canqout of the whole process, rungit reset HEAD path/to/mbox.rbto “unstage” all the hunks you saidyto, and re-rungit add -p. -
Once you’ve said
yto a bunch o’ hunks, you can review the set of hunks you’re about to commit withgit diff --cached. If they look good, then make a commit withgit commit(if you’re used to putting a-aon yourgit commit, now is the time to unlearn that habit). -
Repeat the
git add -p; git diff --cached; git commitdance several times until you’ve committed all the hunks in separate, well-described commits.
You can also use git rebase -i to reorder and squash commits into fewer, larger commits, but that’s a fairly ninja process with a reasonably high probability of getting yourself very, very confused. I only reach for the git rebase -i when I’m in dire straits, myself.