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

[Jonathan Nieder <jrnieder@gmail.com>]

Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:

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

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