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

Junio C Hamano wrote:

Jonathan Nieder [off-list ref] writes:

quoted

	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.

No, I didn't fix that.

What 3/4 allows is

	git reset -- <path1>

The explicit "--" is required in the case where that file is not
present on disk.

quoted

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

Yes, makes sense.  I started out thinking of HEAD as a sort of
abstract symbol (like the occasionally-proposed INDEX) but it probably
is better to get used to it just being a reference early on.

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?

That would eliminate the need for 4/4, I think.  Thanks for the pointers.