Hi, On Mon, Sep 8, 2008 at 10:25 PM, Govind Salinas <govind@xxxxxxxxxxxxxxxxx> wrote: > On Mon, Sep 8, 2008 at 8:05 PM, Steven Walter <stevenrwalter@xxxxxxxxx> wrote: > I had some very different ideas along the lines of reducing the number of > commands (where the commands do something similar just DWIM rather > than force me to remember or read docs on different commands), making > commands look similar to commands from other SCMs (revert should do > what it does for me in all the other SCMs that I have used, which is to > checkout the HEAD copy into the working directory) Your description of revert in various systems isn't quite accurate; it isn't necessarily HEAD, since most systems (at least bzr and hg) can also revert files to revisions earlier than HEAD. In fact, questions of how to do that have come up several times on this list, so you wouldn't want to exclude that case. Also, the revert behavior of git (minus perhaps the default auto-commit) comes in pretty handy too sometimes, and I can't easily find it in other systems (I suspect many just drop back to diff + patch to handle the case that git provides). I don't see why the revert command can't support all these cases that users want (though you'd need to add flags like --since and --in to differentiate between reverting the changes since a given commit or in a given commit). Doing so has the added advantage that you can avoid/deprecate/hide/whatever the second forms of the checkout and reset commands of git, which have long caused confusion for users in understanding the differences between them and the revert command. Elijah P.S. Yes, EasyGit's revert was designed this way. Don't look to eg for implementation guidance, though -- I botched it, and there's a few bugs in it due to my mistakes. I'll be fixing it...when I get a little bit of time. -- 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
