Re: An alternate model for preparing partial commits

> 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.
> 
> Imagine a session like this:
> 
> You've got a couple of conflated changes in your working tree, that
> you think you can break up into two orthogonal changes, each of which
> will compile and pass a set of tests you've got.  You think.  You'd
> like to verify the build and test before you commit each piece.
> 
> git prep
> 
> where "prep" means "prepare commit".  Don't get hung up on command or
> option names I'm using as placeholders, I just made that up without
> much deep thought about what to call it.
> 
> Now my tree appears clean (and git diff returns nothing).  I can now
> start adding the changes I had in my working tree that I want to
> include in the next commit, using git add (which would know I am in
> the "prep" mode).  I can examine those original working dir changes I
> am choosing from with:
> 
> git diff --prep
> 
> which, at this point, shows the same output that "git diff" did before
> I ran "git prep."  Now I want to add some subset of my original
> changes:
> 
> git add newfile.c
> git add -i
> <add a couple of hunks of the changes from file modfile.c>
> 
> Now I have a working tree state that I think I want to commit.  I can
> examine it with:
> 
> git diff
> 
> and I can compile and test it.  Yep, it works and passes my test suite
> (an option I did not have if I had added these changes to the index).
> So now I want to commit:
> 
> git commit -a -m "made change A"
> 
> I think the commit should probably "pop" the rest of the changes I did
> not commit back into the working directory.  If I want to pull another
> subset of changes again, I can repeat the process with another "git
> prep".
> 
> Does this idea resonate with anyone else?