Re: An alternate model for preparing partial commits

From: Stephen Sinclair <radarsat1@gmail.com>
Date: Jun 27, 2008, 20:31 UTC
Message-ID: <9b3e2dc20806271331l2870ef94o4cd413ee40ab0d39@mail.gmail.com>
In-Reply-To: <9af502e50806271014l661dcfc9o4f61ee2b54677bd6@mail.gmail.com>

Hello,

On Fri, Jun 27, 2008 at 1:14 PM, Robert Anderson <rwa000@gmail.com> wrote:

Show 13 quoted lines

> On Fri, Jun 27, 2008 at 6:33 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> 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