From: Junio C Hamano Date: Tue, 19 Oct 2010 23:08:07 GMT Subject: Re: [PATCH 4/4] reset: accept "git reset HEAD " from unborn branch Message-ID: <7vzku9ye5k.fsf@alter.siamese.dyndns.org> In-Reply-To: <20101019221415.GG32029@burratino> Jonathan Nieder writes: > If I try: > > ... hack hack hack ... > git add . > rm ; # bad file! > git reset > > git will respond by informing me that this use of 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 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.