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