Re: Revert behavior [Was: Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain]

["Elijah Newren" <newren@gmail.com>]

On Tue, Sep 9, 2008 at 11:29 AM, Steven Walter <stevenrwalter@gmail.com> 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).