2011/8/16 Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx>: > I had to think about that explanation for a while (partly because "git > add" does not alter the wt either). So, your patch would support the > following workflow: > > git add foo # have index == wt > hack foo # change foo in wt > git update-index --swap foo # add foo and reset to previous state > > Am I understanding you right? The option could trickle down to "add". Well, the point is I want to skip the first phase of normal edit path (wt -> index -> commit) and edit index directly (even in parts that are not touched by wt, which means "git add -e" is useless), leaving my wt "unchanged". Sometimes wt is just too dirty I don't want to make any more changes to it while I focus on "index -> commit" phase. I could add an option to fire up editor with a temporary file containing current index content and automatically update index after editor is closed. But I'd lose the ability to diff my changes. So I do need to wt to change index without losing my current wt. I have to stash my wt somewhere, and index seems a safe place for that. After swapping, it'd look like index -> wt -> commit, I can do "diff HEAD" to check index vs head. Once I'm done (and create index'), I can swap it back to wt -> index' -> commit. Thinking a bit more, this may have another use case (for lazy guys like me, anyway). Assume I have separate changes in wt and I'm ready to make many commit. I should make good commits, which means tests (or at least a compile to see I don't miss any changes). So I add related changes to index, then swap wt/index so index becomes wt (and old wt hidden in index). Test what is to be committed. Good? Swap back, commit. Repeat with the rest of changes in wt. My current workflow is picking changes I believe should go together, commit, then "rebase -i", stopping at each commit to test. It takes longer (especially when I mis-pick changes). > I share the pov that "add -p with e" sometimes doesn't cut it. But > similarly, the fact that "add -p" can't be used to undo a previous "add > -p" is suboptimal. Both issues could be solved with a 3way stage tool. I > have this on my todo/wish list, and I seem to recall that Jeff or Junio > came up with a few lines of (scripting) code for that. That would depend > on the availability of proper tools, though (e.g. vim in diff mode). That'd be great. -- Duy -- 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