Re: Triggers status?
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
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.