2009/6/9 Björn Steinbrink <B.Steinbrink@xxxxxx>: >> Crazy idea: we could actually make 'git revert' do both: given a >> commit, it applies the reverse as it does now. Given filenames, it >> simply brings them back to HEAD. But maybe that's too crazy. Probably too crazy (too much potential for confusion), but an interesting thing about the way eg revert was written is that any valid git revert command passed to eg revert is invalid syntax, so I can print the simple error message: If you are used to git revert, try 'eg cherry-pick -R <ARGS>'... That prevents accidental misuse and misunderstandings, such as these: > Doesn't seem that crazy to me. But maybe a bit problematic if you want > to support both, "git checkout -- ." and "git checkout HEAD -- .". And > adding DWIMmery there seems dangerous, as in: > > git revert == git checkout -- . > > git revert HEAD == > no uncommitted changes = revert commit HEAD > uncommitted changes = revert to HEAD I was thinking that if people had too much heartburn over changing the meaning of revert from "revert-commit" to "revert-edits", then we could always submit the eg revert functionality as git-revert-edits. -- 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