Re: Revert behavior

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

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