Okay, let's step back a bit.
We taught "git show" to show other objects than commits, by doing the
obvious things. So there _is_ a precendent to changing a commands
behaviour to accept more than just commits. And there was already another
command for the same purpose, cat-file, which was never meant as
porcelain however.
Now, what does "revert" _mean_? At the moment, it wants a commit, and
will undo the changes that commit introduced, _and commits it_ (asking
for a message).
What would I expect "git revert -- file" to do? It would undo the changes
to that file -- and since no commit was specified, I would expect it to
look at the changes against the index. (IOW exactly what Steven
proposed.)
To continue the analogy, it would have to commit the undoing of the
change. But since that change never was committed, I think it is more
natural to _not_ commit it.
In the same way, I would expect "git revert <commit> -- file" to undo the
changes in that commit to _that_ file (something like "git merge-file
file <commit>:file <commit>^:file"), but this time commit it, since it
was committed at one stage.
IMHO this would be a consistent behaviour _and_ help new git users.
After all, we are not Python, supposedly narrowing users down to
one-way-to-do-things only.
Ciao,
Dscho
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html