On Mon, Jul 27, 2009 at 12:06:10PM +0200, Thomas Rast wrote: > > 5. Commit 'b' on top of new HEAD (and this would probably actually > > mean the changes from 'b' to the old HEAD, not setting the new HEAD > > state to what's in 'b'). > > > > So it's sort of a generalized form of the index, where you have N "index > > registers" and you sort your changes into them. And during steps 2 and > > 3, you could also make more changes, pick them out, etc. > > I think the parenthetical remark actually contradicts the notion that > it's an index. It's more like a place to hold a patch. Which then > makes it rather similar to a temporary branch and cherry-pick, or > interactive rebase, or whatever. Sort of. It's not an index in the sense that you might make a tree and commit directly from it. But I think of it as an index in that it holds a particular state, and you can diff that state against other things. I would probably implement it as an index via GIT_INDEX_FILE (though I guess performance would not be as nice as if it shared the cache parts of the main index). Implicit in my thinking was that you could actually get rid of the concept of "the index" and simply replace it with such a register (which maybe would be the "default register" or something). So whether you committed directly from it, or whether you applied its diff would be decided not at creation time, but at the time you wanted to commit. And that would depend on what operations you were doing (simply making a commit, sorting changes for multiple commits, etc). > Granted, the register idea does not directly map to interactive rebase > because that cannot (automatically) add changes to an older commit. > So I frequently wind up making a series of commits along the lines of > > WIP implement foo > WIP implement bar > WIP fix foo some > WIP docs for bar > WIP docs for foo > WIP tests for foo > > and then have to sort and squash them with rebase -i. Yes, I do that a lot. And maybe this whole thing is a stupid idea; git already has lots of tools for working with _commits_, so maybe registers should really just be commits. So in that sense what I am asking for is just a multi-headed stash, and tools for doing interactive, incremental stashing to those heads. -Peff -- 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