Hello, On Fri, Jun 27, 2008 at 1:14 PM, Robert Anderson <rwa000@xxxxxxxxx> wrote: > On Fri, Jun 27, 2008 at 6:33 AM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: >> Now, this is not necessarily what everybody wants, which is why many >> people are fine with the index. > > But it is something they should want, and should have, if they care > about the quality of their commits. Especially in the common case of > a project with development lines which have some sort of policy about > build/test requirements. How do you ensure your commits obey that > policy if you cannot verify it? That is why the index is not a > sufficient mechanism for preparing partial commits. It's fine for > quick and dirty operation when the factorization of the conflated > changes is obvious and trivial. It is not sufficient otherwise. I just thought I'd throw in my $0.02 here. There's something fundamental I think I'm not getting about this argument: it seems to be based on the premise that partial commits allow untested tree states to enter the repository. However, having gotten used to the git way of things, I personally don't see the problem with allowing bad commits, as long as they are not pushed to public. That is, I use the git add -p command all the time when I realize I've just done two things that should be committed separately. Then I'll git commit everything else, and go back and test, like so: git checkout master [hack hack..] git add -p git commit git commit -a [test..] git checkout master^ [test..] git checkout master See? All tested. If I find a problem during testing, I'll probably commit it and then rebase master off my new commit, fixing any conflicts I just introduced. Frankly I hardly even use the stash; since history can be edited, I feel like commits are all I need when working with git. Anything I do doesn't matter until I push to public anyways. So it's up to me to make sure I test everything before pushing, but otherwise I'm very happy with the ability to commit half-baked ideas and then go back to make sure they are usable (and tested!) before pushing. This is what local branches are for, isn't it? Steve -- 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
