Hi, On Thu, Oct 30, 2008 at 9:20 AM, Matthieu Moy <Matthieu.Moy@xxxxxxx> wrote: > Theodore Tso <tytso@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
