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

["Steven Walter" <stevenrwalter@gmail.com>]

On Tue, Sep 9, 2008 at 4:19 PM, Elijah Newren <newren@gmail.com> wrote:
>> 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]
[...]
> 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.

The harm I see in trying to support every possible use case is that it
makes it exponentially more difficult to fully understand the tool.
Using yap as an example, I think it should be easy enough for a user
to read the help blurb for every command and understand what it does
and when to use it (this is easy for me to say as the author, but I
think it would hold true for a "typical SCM user.")   Having a mode
the seems to act like another SCM (revert --since) seems great at
first blush.  The user will see that and think, "Wonderful, this will
work just like svn and I don't have to think about it."  As I mention
in another email, that's all well and good until the user runs "git
diff" and makes a liar of you.  In svn, there would be no diff,
because the files all match their respective upstream versions.  In
git, you would see changes because the file no longer matches the last
commit.  Now your user is confused because his mental model was
violated.

Obviously, there is a trade-off here between power and usability.  As
shown by the Hole Hawg[1], there is a limit to the amount of power it
is useful for the average user to have.  The git community has already
admitted this by dividing the git command set into two classes:
plumbing, and porcelain.  "The plumbing," you say, "is very powerful,
but you shouldn't have to use it."  My contention is that there is a
class of users that is not well served by the current definition of
porcelain.  It is that class of users that I have tried to target with
yap.

[1] http://www.cryptonomicon.com/beginning.html
-- 
-Steven Walter <stevenrwalter@gmail.com>
"A human being should be able to change a diaper, plan an invasion,
butcher a hog, conn a ship, design a building, write a sonnet, balance
accounts, build a wall, set a bone, comfort the dying, take orders,
give orders, cooperate, act alone, solve equations, analyze a new
problem, pitch manure, program a computer, cook a tasty meal, fight
efficiently, die gallantly. Specialization is for insects."
 -Robert Heinlein