Daniel Barkalow <barkalow@xxxxxxxxxxxx> 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. -- 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
