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

Jonathan Nieder [off-list ref] 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.