yoush.homelinux.org

I’ve mentioned git add --patch recently.

I’ve used it for some time, and found that it is even more cool than I thought. Not only it allows to select particular file changes to add into commit (while not adding other changes in the same file). It also allows to edit those changes in-place!

Say, you added some debugging code. You want to keep it, but not enabled by default, so you made it #ifdef-ed. And ant the top of your file, you added something like

/* Define this to get debug messages */
#define EXTRA_DEBUG_MESSAGES

You have this in your working directory, but in the commit that adds it, you want #undef instead of #define. Because addition of extra debugging messages is a single logical change that should become a commit, while enabling/disabling those is somewhat that you do in your working directory, and that has zero reasons to be stored in project’s history.

And git add --patch allows exactly that! When it asks what to do with a particular hunk, one of your choices is “edit”. If you choose that, a editor is fired up containing the hunk in diff -u format. Not all edits are safe, but lines marked as + may be changed or deleted. If you delete a line, you don’t need to change the top line containing line numbers – just leave it untouched, git add --patch will do the magic. If you do an unsave change, git add --patch will inform you and give you a chance to recover.

So you can change #define to #undef, or fix a just-noticed typo, or choose not to add something into this commit.

With such a tool available, is there any single reason left not to follow “commit per logical change” policy?