On Fri, Jun 27, 2008 at 6:33 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi, > > On Thu, 26 Jun 2008, 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. > > Half-baked is probably too strong a word. It is too subtle. That the index state - which becomes the next committed state - is not available for building or testing before committing is a deep flaw. > What you are basically asking for is to have the working directory > as staging area, and to be able to stash away changes that are not to be > committed. Correct. > Now, this is not necessarily what everybody wants, which is why many > people are fine with the index. But it is something they should want, and should have, if they care about the quality of their commits. Especially in the common case of a project with development lines which have some sort of policy about build/test requirements. How do you ensure your commits obey that policy if you cannot verify it? That is why the index is not a sufficient mechanism for preparing partial commits. It's fine for quick and dirty operation when the factorization of the conflated changes is obvious and trivial. It is not sufficient otherwise. > Having said that, I played with the idea of a "git stash -i", which would > allow you to select the changes to stash away. (And by extension, "git > stash -e" using the "git add -e" command.) > > Hmm? I meant to mention that - at least in the model I described - this has some overlap with "stash" and could possibly be folded into it. In my ideal UI, changes (from all changes to hunk level) could be moved back and forth between the stash and the working tree equally easily. Would git stash -i allow that? For example, if I moved a couple of files into the stash, and then realized I needed one hunk back, could I easily retrieve just that from the stash? 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
