Re: Revert behavior

[Junio C Hamano <gitster@pobox.com>]

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