Thread (2 messages) 2 messages, 2 authors, 2016-06-15

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

From: Ramkumar Ramachandra <hidden>
Date: 2016-06-15 22:57:23

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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help