Re: [PATCH 1/2] sha1_name: fix error message for @{u}

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: May 21, 2013, 17:56 UTC
Message-ID: <CALkWK0mTWtJ_U1O7ZkNU3aNFwGH456xtmDJhhmS3z1tfwFPNgA@mail.gmail.com>
In-Reply-To: <7vtxlwp9mf.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 12 quoted lines

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