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? Thanks, Bob Anderson -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
