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