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