Re: [PATCH 4/4] reset: accept "git reset HEAD <path>" from unborn branch

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 19, 2010, 23:08 UTC
Message-ID: <7vzku9ye5k.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20101019221415.GG32029@burratino>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 9 quoted lines

> 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.