Re: An alternate model for preparing partial commits

[Dmitry Potapov <dpotapov@gmail.com>]

On Fri, Jun 27, 2008 at 10:14:05AM -0700, Robert Anderson wrote:
> 
> It is too subtle.  That the index state - which becomes the next
> committed state - is not available for building or testing before
> committing is a deep flaw.

And why is that? It is like saying that any editor that does not allow
you to compile the file without saving it first has a deep flaw.

In Git, commits are not the same as in CVS. You can commit any changes
and amend them any time later before you publish your changes. So, what
you normally do is to commit your changes and then run test on them.
The advantage of this approach is that you can continue to your normal
work while test are running, besides the tests are running in clear and
control environment, not in the developer working director where always
there is some garbage.

> > 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.

Those who care about quality should have a review process, and the
review process works best when all changes are slit in a small logical
steps. How do you propose to that without committing changes first?

> 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?

You can verify it, but you do that _after_ you committed changes but
before you publish them. BTW, policy may include that it should be
compiled and tested on a few platforms, so you cannot do that in
your working directory anyway.

I think the source of your confusion is that you consider git commit
as cvs commit, while git commit in some sense may be closer to saving
files, while a better analogue for cvs commit will be git push to a
public repository.

Dmitry