Re: An alternate model for preparing partial commits

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2008.06.26 23:50:06 -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.
> 
> 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?

Hm, I use "stash" for that purpose, which leads to kind of the reverse
of your approach. So I do sth. like this:

 - hack hack hack
 - Notice that I want to make two commits out of what I have in my
   working tree
 - git add -p -- stage what I want in the first commit
 - git commit -m tmp -- temporary commit
 - git stash -- stash away what doesn't belong in the first commit
 - git reset HEAD^ -- drop the temporary commit, with the changes kept
   in the working tree
 - test, fix bugs, read the diff, whatever
 - git commit -- this time for good
 - git stash apply -- get back the changes for the second commit

Instead of using reset, you could also use "commit --amend" (I actually
used to do that), but that needs you to do "git diff HEAD^" to see the
full changes, and (IMHO) makes it a harder sometimes to review your
stuff, because you now have three places where the changes for one
commit might reside (HEAD, index and working tree).

Björn