On Tue, Nov 06, 2007 at 04:54:02AM +0000, Junio C Hamano wrote:
=20
=20
Well, I don't really know how closely you read #git, but I'd say that
"how do I undo my local changes in a git repository" is among the top 3
questions. There _IS_ an UI issue for that.
If git revert <commitish> -- path1 path2 path3 is going to work at some
point, I see no harm in saying that git revert HEAD -- path1 path2 path3
work. We can also in that case spit an error message:
error: this works as a courtesy but you really meant git checkout -- path/t=
o/file
On some other issues I'm all about educating people and learning to
them how to "think different". But here it's a pure interface problem,
and git is the sole $scm with a revert commands that doesn't reverts
local changes wrt HEAD.
The next release of master will have tons of UI improvements (terse
output, better options parsing, more builtins hence faster commands =E2=80=
=A6),
I believe it's stopping halfway not thinking about issues like this from
a newcomer point of view.
On the pure theoretical basis I believe you're right, it's a bit
mixing apples and oranges. On the pragmatic usability side I'm quite
sure you're wrong, because everyone is used to that:
$ hg revert --help | head -3 | tail -1
revert files or dirs to their states as of some revision
$ bzr help revert | head -1
Purpose: Revert files to a previous revision.
$ svn help revert | head -1
revert: Restore pristine working copy file (undo most local edits).
$ darcs help revert | head -3 | tail -1
Revert to the recorded version (safe the first time only).
<put your favorite non-git scm with a revert command here>
--=20
=C2=B7O=C2=B7 Pierre Habouzit
=C2=B7=C2=B7O madcoder@debia=
n.org
OOO http://www.madism.org