Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > If I try: > > ... hack hack hack ... > git add . > rm <path1>; # bad file! > git reset <path1> > > git will respond by informing me that this use of <path1> is > ambiguous. Which is fixed by 3/4. I think that is probably a sane thing to do. > ... So I might try to disambiguate: > > git reset HEAD <path1> I however do not think this is sane, as you are _explicitly_ referring to HEAD, saying "I want to pull this out of the commit pointed by the HEAD", while there is _no such commit_. Sounds somewhat insane. But why is path1 ambiguous in the first place? It is because it is not considered to be a pathname, and it is not a valid refname either, right? Didn't we discuss a separate topic to teach verify_filename/non_filename to optionally look into the index? If we did that, perhaps we do not even need 3/4, no? We could make it the caller's responsibility to run read_cache() before calling these two functions (verify_filename() and verify_non_filename() will just use active_cache[] without reading the index themselves). Alternatively, we could add a new option "use_index" (0: do not use index at all, 1: run read_cache() to the_index and use it for checking, 2: run read_index() on a temporary in-core index, use it for checking and then discard the temporary in-core index to keep them free of side-effect) to them. I haven't looked at all the call sites of them to see which one is better, 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