Re: [PATCH 2/2 v3] sha1_name: teach get_sha1_1 "-" shorthand for "@{-1}"

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 13, 2017, 20:03 UTC
Message-ID: <xmqqwpctdfj9.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqq1sv1euob.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 27 quoted lines

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Siddharth Kannan <kannan.siddharth12@gmail.com> writes:
>>
>>> +	if (!strcmp(name, "-")) {
>>> +		name = "@{-1}";
>>> +		len = 5;
>>> +	}
>>
>> One drawback of this approach is that further error messages will be
>> given from the "@{-1}" string that the user never typed.
>
> Right.
>
>> There are at least:
>>
>> $ git grep -n -A1 'strcmp.*"-"' | grep -B 1 '@\{1\}'
>> builtin/checkout.c:975: if (!strcmp(arg, "-"))
>> builtin/checkout.c-976-         arg = "@{-1}";
>
> I didn't check the surrounding context to be sure, but I think this
> "- to @{-1}" conversion cannot be delegated down to revision parsing
> that eventually wants to return a 40-hex as the result.  
>
> We do want a branch _name_ sometimes when we say "@{-1}"; "checkout
> master" (i.e. checkout by name) and "checkout master^0" (i.e. the
> same commit object, but not by name) do different things.

FYI, the "@{-<number>} to branch name" translation happens in interpret_branch_name(). I do not offhand recall if any callers protect their calls to the function with conditionals that assume the thing must begin with "@{" or cannot begin with "-" (the latter of which is similar to the topic of patch 1/2 of this series), but I suspect that teaching the function that "-" means the same as "@{-1}" would bring us closer to where we want to go.