Re: [PATCH] Documentation: add a planning document for the next CLI revamp

From: Elijah Newren <newren@gmail.com>
Date: Nov 1, 2008, 19:42 UTC
Message-ID: <51419b2c0811011242k439c1504ve15dc2faff262224@mail.gmail.com>
In-Reply-To: <vpqmygmw1mr.fsf@bauges.imag.fr>

Hi,

On Thu, Oct 30, 2008 at 9:20 AM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:

Show 11 quoted lines

> Theodore Tso <tytso@mit.edu> writes:
>
>> * Add the command "git revert-file <files>" which is syntactic sugar for:
>>
>>         git checkout HEAD -- <files>
>
> I don't think "revert-file" is a good name for this: although other
> SCM often call this "revert", what Git calls "revert" is about
> reverting an existing commit (it's "backout" in hg for example). The
> terminology to revert the working tree to the last commited version is
> already here in Git, it's "reset".

git's reset is _not_ the same as svn/bzr/hg's revert; and it's overlap in functionality is smaller than you realize.

> I've already argued in favor of allowing "git reset --hard <files>",
> which is consistant with existing terminology and doesn't add an extra
> command, but without success.

Such a command would
  * delete newly added files instead of simply untracking them.
That's the right thing for reset, but not for a svn/bzr/hg-like revert
(and unfortunately means unintended data loss.)
  * doesn't make sense during an incomplete merge, unless you add some
way of specifying which branch users want to revert their files back
to.  Aren't there enough confusing flags for reset already?  (One
surprisingly common comment I get about eg is that git reset is too
hard to understand and eg reset fixes it -- despite the fact that I
merely renamed two flags and hid the second form of the command.)
  * doesn't work for the initial commit
  * provides no way to revert files or subdirectories back to their
state at some previous revision (hg and bzr revert have a flag to
provide this; it's not useful all the time but is on occasion)  Also,
if users try to modify their command slightly to get such behavior,
say 'git reset --hard REVISION' instead of 'git reset --hard .', then
they're in trouble.  (Recoverable, but they need an 'expert' to help
them now.)

Also, there's three different kinds of "undo": switching to an old revision (git checkout REVISION, or svn/hg update -r, etc.), forgetting or discarding commits/merges/rebases (git reset), and modifying files to undo previous modifications without touching HEAD (svn/bzr/hg revert). Users get confused enough between these different kinds of undo; overloading them further would be really bad, IMO.

(Part of the reason for users getting confused between these kinds of undo is the fact that git doesn't implemented svn/bzr/hg-like revert, and tends to steer them towards git checkout and git reset, which are commands typically meant for the *other* kinds of undo.)

Just my $0.02, Elijah