On Fri, Jul 24, 2009 at 10:24 AM, Thomas Rast<trast@xxxxxxxxxxxxxxx> wrote: > The new command 'git unstage' is the precise opposite of 'git stage' > (i.e., git-add). As such, it is the same as 'git reset --' unless the > current branch is unborn. I really, really like the idea of being able to do something like unstage -p. That's sweet, thanks for working on that. Some potential issues, though: git unstage may cause issues for some people if they try to use it when in the middle of a merge (why reset back to HEAD rather than one of the other branches being merged?). With git reset, one can specify which commit to reset the index back to. With your 'unstage' command, you not only assume 'HEAD' but don't allow specifying any other value. You could add a commit argument here, but that may be problematic wording-wise, in that you're allowing to 'unstage' back to a specified commit, with the possibly perplexing result that you have 'staged' something else. Also, you have added two new commands, unstage and discard, which are two pieces of an hg-like revert (revert edits). We still don't have a command for a full hg-like revert, though (git checkout does not cover the bases), and to cover that we'd have to add a third command. Perhaps the three could be combined? Elijah -- 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