From: Petr Baudis <pasky@suse.cz>
Date: Fri, 27 Jun 2008 08:50:07 GMT
Subject: Re: An alternate model for preparing partial commits
Message-ID: <20080627085007.GE12567@machine.or.cz>
In-Reply-To: <9af502e50806262350t6e794a92g7751147f1882965@mail.gmail.com>

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

-- 
				Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson