Ian Jackson wrote:
I can see that that would be helpful but in practice doing things that way makes the coding a lot harder. Normally, for a smallish change, I would definitely try to make separate patches for anything else I stumbled across. Likewise if I thought there was a serious possibility that some of my changes would need to remain as a separate branch for a long time while others are merged into the trunk.
How is it a lot harder to keep things simple? For instance, if you add a new locking mechanism, then modify the existing code to use the new system, the new locking mechanism should not disturb existing code since it is new, so it can easily be committed as it's own logical change. Then commit the modification of the existing code to use the new locking mechanism separately, and now the locking mechanism and its use can be reviewed easier in their own right.
One person might review the locking mechanism commit but know nothing about the existing code you later change to use it. That may lead to him deciding to convert some other code to use it, or suggest some changes to it. It makes his life easier when he doesn't have to sort through a larger patch that also contains a bunch of code he doesn't have any familiarity with.
But when one's doing the kind of substantial engineering required in this case, the extra mindspace needed to retain the different branches, merge the bugfixes in the right way, and so forth, is often better spent on remembering how all of the code and semantics fitted together.
Reviewing the changes is MUCH easier in bite sized chunks, and going through the trouble of figuring out which parts are logically independent and can be cut as separate commits ends up helping you to better understand what you are doing as well. In 6 months when you come back to the code and forgot it all, reviewing the shortlog for 30 seconds is more likely to refresh a lot more of your memory with smaller commits too. Then you have debugging... while trying to narrow down which change introduced a bug, having small commits allows git-bisect to help you quickly figure out EXACTLY which change caused the problem.