On Tue, Jun 9, 2009 at 9:32 PM, Theodore Tso<tytso@xxxxxxx> wrote:
> My personal opinion is this kind of overloading is actually more
> confusing than simply adding a new name, such as "git revert-file".
> Of course, you can do that already using a git alias.... So IMHO the
> best way of handling this issue is to have git tutorials use this as a
> teachable moment, so people can create their own git alias for "git
> checkout HEAD --".
So I have a few problems with such an alias:
* It fails to work during an initial commit ("git revert-files
new-file" -> "fatal: invalid reference: HEAD")
* When not working on the initial commit, it will silently do nothing
when given a newly added file rather than undoing the add
* As a side effect of the above, trying to undo all changes via "git
revert-files ." does not actually work; any newly added files will
still remain staged.
* It makes no sense during an incomplete merge (why is HEAD more
special than other refs in $git_dir/MERGE_HEAD? Shouldn't the user
need to specify which ref to revert relative to in such a case?)
* It can't be used to revert a file back to a revision prior to HEAD
(and 'git checkout OLDER_COMMIT -- FILE' in such a case isn't always
the right match either as it can leave the file in the working copy
when it should be removed).
* It provides no option to make the changes to just the index or just
the working copy; it always affects both (which is the right default,
but sometimes I like making changes to just one of those two places).
"git checkout <commit> -- <paths>..." really is a different command
than the "revert" of svn, bzr, darcs, or mercurial. There's clearly a
lot of overlap, but they're not the same. I fear that claiming they
are equivalent will at some point just cause extra confusion for new
git users.
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