On Sat, 6 Oct 2007, Andy Parkins wrote: > > Who cares? Commits that build isn't the only reason for small commits. More importantly, while it's true that you should always test all your changes, quite often they really *are* obviously separate. I've mentioned this as an example lots of times, but I often tend to have multiple independent things in my tree at the same time. One of the "clearly independent" ones is the fact that I historically tended to update my Makefile for the next version number several days before I do the actual release, just to remind me (I used to forget to bump the version number, so..). So I often have a dirty main makefile, but that doesn't mean that I'm going to commit it until I'm ready. I want to (no - *need* to) be able to pull and apply patches from other people despite the fact that I have some dirty state. [ It's not just the makefile: almost all of what I do these days is pull and apply patches, but I also send out suggestions to other developers by email, and I often end up keeping my suggestion around in my tree as dirty state. I could use a topic branch, but the thing is, I don't actually want to save it - but not only do I actually like seeing the "couldn't merge due to dirty state" because that tells me I got the fix back, but I like just eatign my dogfood and compiling the kernel with the suggestions I sent out ] So it's quite ok to have multiple independent changes going on it the tree, and there's absolutely *zero* reason to think you should commit them together (quite the reverse). Maybe this isn't all that common for a *small* thing, but I pretty much guarantee that large projects always end up doing somethng like this. And making the *default* workflow do something bad - namely commit everything blindly - is not a good idea. I'd rather have the normal workflow basically try to encourage many small commits, because while it's true that they may not have been tested individually, 99% of the time any linkages are pretty obvious. (Side note: the *most* common failure to check stuff in completely tends to be one that other SCM's also have, for all the same reasons: forgetting to *add* a new file. I suspect the git model of "add all new changes" whether new files or old, actually _helps_ avoid that error, but quite frankly, I don't think we'll ever get away from it. It's just too easy a mistake to do). Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
