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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]