From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 21 May 2013 18:02:11 GMT
Subject: Re: [PATCH 1/2] sha1_name: fix error message for @{u}
Message-ID: <7vfvxgnrdo.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALkWK0mTWtJ_U1O7ZkNU3aNFwGH456xtmDJhhmS3z1tfwFPNgA@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Junio C Hamano wrote:
>> Does a failure in interpret-branch-name that issue these error
>> messages always followed by die() in the caller?  I know you looked
>> at the cases you noticed as an end-user (like the above "git show @{u}"
>> example), but if some codepaths did this:
>>
>>         if (interpret-branch-name()) {
>>                 you do not seem to have upstream defined,
>>                 so I will helpfully do something else that
>>                 you probably have meant.
>>         }
>>
>> this patch will break that codepath you did not look.
>
> How can that ever happen in a non end-user case?  That failure
> requires a string containing "@{u}" to be constructed and passed as an
> argument.  Why would we ever programmatically construct "@{u}" to find
> the upstream?
>
> To put it another way: unless an end-user facing application finds an
> "@{u}" while parsing argv and passes it on to interpret-branch-name,
> isn't it impossible for an "@{u}" to end up in the argument?

So did you or did you not audit the codepath?