Re: Revert behavior

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 9, 2008, 22:10 UTC
Message-ID: <7v63p53r93.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <e06498070809091439q1c543807pd6e74b7ada32434@mail.gmail.com>

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

Show 7 quoted lines

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