git workflow: keeping inconsistent commits in history

Question

I'm newbie in git and I'm trying to use it as follows (AFAIK it's a quite common workflow for a single developer):

• Create a feature branch and do some work on it, with some WIP commits.
• When done, reorganize these WIP commits to well-consistent ones (those that pass compiling and testing) to have a clean history.
• Merge feature branch into master .

Now I'm about migrating some of my projects (related to a single workspace, ie working tree) to a new version of compiler. On a feature branch msvc90 I prepared a lot of work to be committed. I have two options know:

• Create a single big commit (-m "migration to MSVC 9.0").
• Create a number of commits to keep several steps of migration in history (creation of new project files, deletion of old ones, tuning source code to get rid of compiler warnings, bug fixing, etc.). Note that these commits cannot be well-consistent on their own (eg using new project file with untuned source code will result in compilation errors).

My question is quite philosophical. The second option seems to be slightly preferable for me as it keeps more details in history. On the other hand I have read some git tutorials that recommend to keep well-consistent commits only (eg to use bisect).

Does anyone know examples of big projects whose policy permits keeping inconsistent commits of this kind (on feature branches)?

Answer 1

If in doubt, keep the commits small. Bisect allows you to have "don't know" answer instead of just "yes" or "no". More information is always better as you can reduce later if need be. You can't do it the other way around.