On Tue, Sep 9, 2008 at 11:29 AM, Steven Walter <stevenrwalter@xxxxxxxxx> wrote: >> Of course, this is where I would use a DWIM-ism. >> "pyt revert -r commitish" would generate a reverse patch but >> "pyt revert <paths>..." would checkout from HEAD. "pyt revert" would >> just "git reset --hard". > > In yap, "revert" is used to discard working copy changes. "revert -a" > reverts all changes; just "revert" replies "nothing to do." Having > "pyt revert" = "git reset --hard" makes me queasy; especially in > Dvorak it's all too easy to hit Enter when reaching for '/'; seems > like a catastrophe waiting to happen. I agree with that, and a plain "eg revert" does nothing other than provide a suggestion for the user as well. > I tend to dislike "DWIM" in interfaces, because the computer cannot > read your mind, and can therefore never know with certainty what I > mean. Especially in cases where the computer thinks I intend to > perform an irreversible operation, I want the computer to ask first. > Not only that, but I think having one command that does 10 different > things is as confusing as 10 commands that each do one thing. My How are these things really different, though? People occasionally want to "revert changes". Now, this may be the changes between 32 and 29 revisions ago, it might be all changes since the last commit, it could be the changes since 3 commits ago, or it could be just one specific commit. The user may want to subset such reversions to just specific files, but it all boils down to "reverting changes" in the end. Now, eg can't yet handle a range like between 32 and 29 revisions ago (because I wasn't sure what syntax I'd want to use for it), but it's fairly straightforward to say any of: eg revert --since HEAD~3 # Undo all changes since HEAD~3 eg revert --in HEAD~8 # much like git revert HEAD~8, but no commit by default eg revert --since HEAD foo.py # Undo changes to foo.py since last commit eg revert foo.py # Same as above eg revert --in trial~7 bar.c baz. # Undo changes made in trial~7 to bar.[ch] What doesn't work is eg revert trial~7 since I don't know whether the user wants to revert changes in that commit, or since that commit (so this is a minor backward compatibility break I made with core git). But eg provides a simple warning with suggestions, which teaches the user the correct command as well as potentially showing them some new functionality. Are these kinds of "reverting data" really so different that there should need to be different commands, or that some of these operations shouldn't be supported by the simple revert command? Sure, most users most of the time will probably use the "eg revert FILE1 FILE2..." form, but I didn't see the harm in supporting the extra capabilities. Also...is there anything fundamental that would keep core git from adopting such behavior? It'd solve lots of user questions[1], but would also have some potential backward compatibility issues for scripts[2] (which may be reason enough to not adopt it, I know). Elijah [1] For example, "how do I revert all changes since commit x?", "how do I revert the recent modification to a certain file?", and "what's the difference between checkout, reset, and revert?" [2] commits by default don't make sense for the generalized revert command, and "git revert REVISION" would error out with instructions (telling the user to add the --in flag). -- 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
