Re: Question about "git commit -a"

On Sat, 6 Oct 2007, Andy Parkins wrote:

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