On Fri, Jun 27, 2008 at 1:50 AM, Petr Baudis <pasky@xxxxxxx> wrote: > 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. I think if you read the whole message the answer to your question is there. > 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? As I said in my original message, twice, was that the index state is never instantiated and therefore cannot be compiled or tested. Thanks, Bob -- 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
