Daniel Barkalow [off-list ref] writes:
With that description, there's a bug: in addition to the above, it checks
out from the index any path which does match the <paths> but isn't in
<tree-ish>....
...
(instead, you should get an error if a <path> doesn't match anything in
the <tree-ish> and only get those things that it matches in the
<tree-ish>.)
I think I was too zealous sharing code back in February. I should have a
patch by the weekend if nobody beats me to it. (And I still think that, if
you hit this case, you must be confused, but git isn't helping by doing
what it does.)
I think that may be a good thing to do.
By the way, I am not opposed to have "git $revert <tree-ish> <path>..."
that makes the work tree and the index identical to what existed in
<tree-ish> at the named <paths>, i.e. checking out "the absense" of files
in the named directory if <path> is a subtree. Because it is very
established to use the command verb "revert" to mean making a
counter-commit by now, we may have to use a word other than "revert" for
that purpose, though.