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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Oct 19, 2010, 23:26 UTC
Message-ID: <20101019232647.GA6198@burratino>
In-Reply-To: <7vzku9ye5k.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

> Jonathan Nieder <jrnieder@gmail.com> writes:

Show 8 quoted lines

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

Show 7 quoted lines

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

Show 6 quoted lines

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