Re: An alternate model for preparing partial commits

["Robert Anderson" <rwa000@gmail.com>]

On Fri, Jun 27, 2008 at 11:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
> I've always said that I am not in favor of any form of partial commits,
> exactly for the reason Robert states, namely that you are not committing
> what you had in your work tree as a whole.  I said so back when the only
> form of partial commits were "git commit [-o] this-file".  I said it again
> even when I introduced "add -i", that the interface goes backwards and
> does not fix the issues associated with partial commits.

We are seeing eye-to-eye here.

> But I agree with you that calling the index half-baked is missing the
> point.

What I said is that the index is a half-baked version of _what I
want_, which is the ability to do partial commits from testable
states.  Clearly the index is a way to do partial commits, but it does
not address the "untested state" issue, so it is only halfway there,
i.e., half-baked.

> The index is merely the lowest level of facility to stage what is
> to be committed, and there is no half nor full bakedness to it.  The way
> the current Porcelain layer uses it however could be improved and Robert
> is allowed to call _that_ half-baked when he is in a foul mood (even then
> I would rather prefer people to be civil on this list).

Fair enough.  I did not mean "half baked" to be particular provocative, fwiw.

> I would actually go the other way.  I think the problem we are trying to
> solve here in this thread is to support this (other) workflow:
>
>    You keep working, and eventually build all the changes intermixed in
>    your work tree, perhaps without any commit, or perhaps with a commit
>    sequence that is only meant as snapshots and not as a logical
>    sequence.  Your work tree state is in good shape right now (you do
>    build and test at this "commit goal" state).  Now you would want to
>    split the changes while making sure each step is good (i.e. builds and
>    tests fine as well as the patch makes sense standalone).
>
> One thing I think would make sense is to stash away _everything_ at this
> point.  That would take you to the state before you started working.  Then
> if we can selectively _unstash_ the parts that should logically be
> committed first to bring them to your work tree, then you can inspect that
> change against HEAD, test it, and when you are happy with it, you would
> make your first commit in the final sequence.

Exactly.  That was a good summary of the workflow I proposed in my
original email.

> Once you have capability to unstash selectively and make that first commit
> in the final sequence like so, breaking up the remainder that is still in
> your stash to a reasonable sequence of commits can be done with the same
> workflow.  Unstash the next batch, inspect, test and be satisfied and then
> commmit.  Lather, rinse and repeat.

Bingo.

Time permitting, I will propose a more well thought through UI for
this workflow.  If you like it, we can talk about how it might be
implemented.

Thanks,
Bob