Re: An alternate model for preparing partial commits

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

On Fri, Jun 27, 2008 at 1:50 AM, Petr Baudis <pasky@suse.cz> wrote:
>  Hi,
>
> On Thu, Jun 26, 2008 at 11:50:06PM -0700, Robert Anderson wrote:
>> Seems to me the concept of the "index" is a half-baked version of what
>> I really want, which is the ability to factor a working tree's changes
>> into its constituent parts in preparation for committing them.  The
>> index provides some very nice facilities to factor out changes in a
>> working tree into a "staging area", but the fundamental flaw of this
>> in my view is that this "staging area" is not instantiated as a tree,
>> so it cannot be compiled and/or tested before committing.
>>
>> Consider a facility where the state you want to commit next is built
>> up in the current working directory, and the original set of changes
>> exists in some proto-space like the index currently inhabits, where
>> you can query and manipulate that state, but it isn't instantiated in
>> your working tree.
>
>  I wanted to suggest using commit and commit --amend, but I realized
> that frankly, I don't understand quite what are you wanting to do.

I think if you read the whole message the answer to your question is there.

> Through the process, are you preparing a sequence of two commits at
> once, or merely a single commit? With s/--prep/--cached/ and throwing
> git prep away completely, it's not clear to me how would what you
> present be different at all from just using index - could you point out
> what is actually different in your workflow compared to the prep
> workflow you propose?

As I said in my original message, twice, was that the index state is
never instantiated and therefore cannot be compiled or tested.

Thanks,
Bob