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

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

[Elijah Newren]

Hi,

On Mon, Sep 8, 2008 at 10:25 PM, Govind Salinas
<govind@sophiasuchtig.com> wrote:
> On Mon, Sep 8, 2008 at 8:05 PM, Steven Walter <stevenrwalter@gmail.com> 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.

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

[Jakub Narebski]

Elijah Newren wrote:
> On Mon, Sep 8, 2008 at 10:25 PM, Govind Salinas
> <govind@sophiasuchtig.com> wrote:
> > On Mon, Sep 8, 2008 at 8:05 PM, Steven Walter <stevenrwalter@gmail.com> 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).
[...]

By the way, I think the fact that in different SCMs meaning of
"$scm revert" and of "$scm reset" differs widely caused Mercurial
to adopt "hg backout" for creating a commit which reverts changes
(cherry-pick -R), and "hg rollback" to undo last commit.

-- 
Jakub Narebski
Poland

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

[Govind Salinas]

On Tue, Sep 9, 2008 at 8:38 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Elijah Newren wrote:
>> On Mon, Sep 8, 2008 at 10:25 PM, Govind Salinas
>> <govind@sophiasuchtig.com> wrote:
>> > On Mon, Sep 8, 2008 at 8:05 PM, Steven Walter <stevenrwalter@gmail.com> 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).
> [...]
>
> By the way, I think the fact that in different SCMs meaning of
> "$scm revert" and of "$scm reset" differs widely caused Mercurial
> to adopt "hg backout" for creating a commit which reverts changes
> (cherry-pick -R), and "hg rollback" to undo last commit.
>

My take on this comes from my own personal experience with "revert"
commands, the fact that "how do i undo my working dir changes" is
the most common question I see on the list and that I have heard
others with the same complaint.

I will concede that revert usually means both "discard current working
dir changes" and "undo a previous change" in different circumstances.
However, the number of times that "how do i discard my working
dir changes" comes up on the list leads me to believe that you get
the most out of using revert for this, since it is something that should
be familiar to a user and undoing a previous commit is more rare.

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".

-Govind

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

[Steven Walter]

On Tue, Sep 9, 2008 at 12:37 PM, Govind Salinas
<govind@sophiasuchtig.com> wrote:
> My take on this comes from my own personal experience with "revert"
> commands, the fact that "how do i undo my working dir changes" is
> the most common question I see on the list and that I have heard
> others with the same complaint.
>
> I will concede that revert usually means both "discard current working
> dir changes" and "undo a previous change" in different circumstances.
> However, the number of times that "how do i discard my working
> dir changes" comes up on the list leads me to believe that you get
> the most out of using revert for this, since it is something that should
> be familiar to a user and undoing a previous commit is more rare.
>
> 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 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
philosophy has been to identify frequent operations and give them
sensible commands, rather than overloading a handful of operations or
requiring multiple commands for common tasks.  My philosophy has also
been not to wrap every command.  If a user were to ask me, "I want to
bisect a changeset," my response would be "okay, use git bisect."  If
the user wants such a specialized command as that, then they shouldn't
have trouble with dealing directly with git for that operation.
-- 
-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

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

[Elijah Newren]

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).

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

[Elijah Newren]

On Tue, Sep 9, 2008 at 7:38 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> By the way, I think the fact that in different SCMs meaning of
> "$scm revert" and of "$scm reset" differs widely caused Mercurial
> to adopt "hg backout" for creating a commit which reverts changes
> (cherry-pick -R), and "hg rollback" to undo last commit.

Ah, I had somehow missed hg backout.  Thanks for the pointer!

Elijah

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

[Petr Baudis]

On Tue, Sep 09, 2008 at 03:38:13PM +0200, Jakub Narebski wrote:
> By the way, I think the fact that in different SCMs meaning of
> "$scm revert" and of "$scm reset" differs widely caused Mercurial
> to adopt "hg backout" for creating a commit which reverts changes
> (cherry-pick -R), and "hg rollback" to undo last commit.

This brings up a point I wanted to raise - sometimes when the meanings
across the systems (including Git) are too conflicting, it should be
considered to use a completely different command name whatsoever to
reduce the confusion. This is e.g. the reason Cogito had no "pull"
(but "update") or "checkout" (but "restore" and "switch") commands.

				Petr "Pasky" Baudis

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

[Steven Walter]

On Tue, Sep 9, 2008 at 5:28 PM, Petr Baudis <pasky@suse.cz> wrote:
> On Tue, Sep 09, 2008 at 03:38:13PM +0200, Jakub Narebski wrote:
>> By the way, I think the fact that in different SCMs meaning of
>> "$scm revert" and of "$scm reset" differs widely caused Mercurial
>> to adopt "hg backout" for creating a commit which reverts changes
>> (cherry-pick -R), and "hg rollback" to undo last commit.
>
> This brings up a point I wanted to raise - sometimes when the meanings
> across the systems (including Git) are too conflicting, it should be
> considered to use a completely different command name whatsoever to
> reduce the confusion. This is e.g. the reason Cogito had no "pull"
> (but "update") or "checkout" (but "restore" and "switch") commands.

I agree with this.  That's part of the problem I have with schemes to
make commands work similarly to other SCMs.  If you give, for example,
eg a mode to act like "svn revert;" that all well and good until the
user runs "git diff" and you're made a liar.  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.

It it a delicate balance to have the user interface match both the
mental model of the user and the storage model of the tool.  That's
what all of these projects, (git, cogito, yap, eg, pyrite) are
attempting to do.  I don't know of an objective way to measure success
in this attempt, other than simple popularity.  Popularity suggests
that the git porcelain is the most successful, and I would agree
regarding storage model, but I am not convinced that it best matches a
typical SCM user's mental model.
-- 
-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

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

[Steven Walter]

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

Re: Revert behavior

[Junio C Hamano]

"Steven Walter" <stevenrwalter@gmail.com> writes:

> I agree with this.  That's part of the problem I have with schemes to
> make commands work similarly to other SCMs.  If you give, for example,
> eg a mode to act like "svn revert;" that all well and good until the
> user runs "git diff" and you're made a liar.  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.

If you implement "eg svn-like-revert" to checkout the given paths out of
the last commit, instead of the index, shouldn't that be sufficient?

> It it a delicate balance to have the user interface match both the
> mental model of the user and the storage model of the tool.

I do not think it is that simple.

You could match the user experience to the mental model of the other tool,
by hiding the differences and insisting that people use only your tool.

The real issue is that you may need to castrate the underlying tool in
certain places if its world model is richer than the model the tool you
are trying to emulate.  Ignoring the index by making "svn-like-revert"
work on both index and the working tree file at the same time is a good
example of that.

If the castrated feature is truly too exotic and rarely useful for mere
mortals, that strategy works very well.  A simpler world model that lets
you do the same job equally well is a much better UI than the needlessly
complex one.  But if that is not the case, your users would eventually
graduate out of the training wheel and would want to use that feature you
hid away from them, and at that point they need to unlearn parts of the
simpler world model and shift their world view somewhat.  If you try to
support both classes of users, that become hard.

I have to admit that I used to have my own Porcelain when git was very
young, not because I did not like existing UI git had, but there was no UI
back then.  "My own" Porcelain is relatively easy -- I have to only cater
to my own needs and need to expose only the limited subset of the features
the underlying tool (in this case, the storage model and history view of
git) I understand, and nobody complains that he cannot access the parts I
do not expose to him.  Growing it to satisfy wider audience is the hard
part.

Re: Revert behavior

[Steven Walter]

On Tue, Sep 9, 2008 at 6:10 PM, Junio C Hamano <gitster@pobox.com> wrote:
> If you implement "eg svn-like-revert" to checkout the given paths out of
> the last commit, instead of the index, shouldn't that be sufficient?

eg's "revert --since <commit> <path>" command is actually most similar
to "svn update -rXXX path."  In this case, except for the special case
where commit is HEAD, it is not sufficient; checking the path out of
the last commit would not be what the user wanted.

>> It it a delicate balance to have the user interface match both the
>> mental model of the user and the storage model of the tool.
>
> I do not think it is that simple.
>
> You could match the user experience to the mental model of the other tool,
> by hiding the differences and insisting that people use only your tool.
>
> The real issue is that you may need to castrate the underlying tool in
> certain places if its world model is richer than the model the tool you
> are trying to emulate.  Ignoring the index by making "svn-like-revert"
> work on both index and the working tree file at the same time is a good
> example of that.
>
> If the castrated feature is truly too exotic and rarely useful for mere
> mortals, that strategy works very well.  A simpler world model that lets
> you do the same job equally well is a much better UI than the needlessly
> complex one.  But if that is not the case, your users would eventually
> graduate out of the training wheel and would want to use that feature you
> hid away from them, and at that point they need to unlearn parts of the
> simpler world model and shift their world view somewhat.  If you try to
> support both classes of users, that become hard.

Indeed so.  Hiding the index is not a design goal of yap.  However,
neither is it absolutely necessary to understand the distinction
between "staged" and "unstaged" changes to use yap.  If a use never
runs the "stage" command, everything would work as he expects.
Achieving this is as simple as making "yap commit," in the presence of
only unstaged changes, do the equivalent of "git commit -a."  If it
turns out that _wasn't_ what the user wanted, salvation is only a "yap
uncommit" away.

In your position as an integrator, what is a necessary tool for you
may indeed be an exotic command for another user.  For example, users
who primarily interact with svn repositories (a target demographic for
yap), "merge" is not terribly useful given the information loss when a
commit is eventually "pushed" to subversion.  I do not hide merge
functionality, but neither is it emphasized as a standard part of the
workflow (there is no "pull" command).

> I have to admit that I used to have my own Porcelain when git was very
> young, not because I did not like existing UI git had, but there was no UI
> back then.  "My own" Porcelain is relatively easy -- I have to only cater
> to my own needs and need to expose only the limited subset of the features
> the underlying tool (in this case, the storage model and history view of
> git) I understand, and nobody complains that he cannot access the parts I
> do not expose to him.  Growing it to satisfy wider audience is the hard
> part.

No argument that supporting an audience greater than 1 is considerably
more difficult.  Indeed I intend and hope to support users other than
myself with yap, else I would not have gone to the trouble of
announcing it.  However, without concrete discussion on where yap
hides too much or "castrates" a feature in a way that hinders learning
of the lower-level tools, there's only so much one can do.
-- 
-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

Re: Revert behavior

[Elijah Newren]

On Tue, Sep 9, 2008 at 4:10 PM, Junio C Hamano <gitster@pobox.com> wrote:
> If you implement "eg svn-like-revert" to checkout the given paths out of
> the last commit, instead of the index, shouldn't that be sufficient?

No, that would leave staged changes unreverted -- a particular case of
which means that revert wouldn't be able to undo an add operation.
For svn-like-revert, the default should be for both staged and
unstaged changes to be undone, unless the user specifically requested
that only part of the changes be reverted (e.g. with --staged or
--unstaged flags).  Making revert work prior to the initial commit for
new adds is another case that needs a command with behavior different
than git's checkout of paths.

>> It it a delicate balance to have the user interface match both the
>> mental model of the user and the storage model of the tool.
>
> I do not think it is that simple.
>
> You could match the user experience to the mental model of the other tool,
> by hiding the differences and insisting that people use only your tool.
>
> The real issue is that you may need to castrate the underlying tool in
> certain places if its world model is richer than the model the tool you
> are trying to emulate.  Ignoring the index by making "svn-like-revert"
> work on both index and the working tree file at the same time is a good
> example of that.

Why?  If the command _by default_ works on both the index and working
tree file, is that necessarily bad ('git checkout BRANCH' operates on
both)?  If the tool can only operate on both at once, then sure, I
agree, but that at least isn't the case with eg and wasn't my
suggestion for git.

Not all alternate porcelains try to hide or destroy the index.  Some
of us really do love it.


Elijah

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

[Elijah Newren]

On Tue, Sep 9, 2008 at 3:50 PM, Steven Walter <stevenrwalter@gmail.com> wrote:
> On Tue, Sep 9, 2008 at 4:19 PM, Elijah Newren <newren@gmail.com> wrote:
>> 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.

Um, no, git diff won't make a liar of me -- it'll come up empty as
expected.  :-)  My suggestion for revert does make it a logical
extension of svn's, and includes git revert's behavior (with two minor
tweaks).  See my follow up post to Junio's elsewhere in this thread.

> 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.

Fair enough.  I too had to make decisions on what to focus on as well
in Easy Git.  Since my goal was more along the lines of "make it easy
to learn how to use git, and particularly easy to transition to and
from git and eg" that gives me a much different frame of reference
than interoperating with svn (which I essentially ignored).  I thought
that this particular case didn't add much complexity (and potentially
even removed it elsewhere), but that may just be my frame of
reference.

yap looks pretty cool; I'll have to take a look sometime.