Re: [PATCH] branch: fix funny-sounding error message

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alex Henrie <alexhenrie24@xxxxxxxxx> writes:

> 2015-05-03 17:54 GMT-06:00 Junio C Hamano <gitster@xxxxxxxxx>:
>> Alex Henrie <alexhenrie24@xxxxxxxxx> writes:
>>
>>> Signed-off-by: Alex Henrie <alexhenrie24@xxxxxxxxx>
>>> ---
>>>  builtin/branch.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/builtin/branch.c b/builtin/branch.c
>>> index 1d15037..c0b4bae 100644
>>> --- a/builtin/branch.c
>>> +++ b/builtin/branch.c
>>> @@ -972,7 +972,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
>>>
>>>               if (!branch) {
>>>                       if (!argc || !strcmp(argv[0], "HEAD"))
>>> -                             die(_("could not set upstream of HEAD to %s when "
>>> +                             die(_("could not set upstream of HEAD to %s because "
>>>                                     "it does not point to any branch."),
>>>                                   new_upstream);
>>>                       die(_("no such branch '%s'"), argv[0]);
>>
>> Thanks.
>>
>> To me neither sounds so funny, but both sound somewhat awkward,
>> primarily because it is unclear in the first reading what "it" in
>> "it does not point at any branch" refers to.
>>
>> Perhaps if you explain in the log message to illustrate why you
>> found it funny (and the update text is not), it might help, e.g.
>>
>>     "git branch", ran with <this and that options>, when the current
>>     branch is <in what state>, dies with
>>
>>         fatal: could not set upstream of HEAD to frotz when it does not
>>         point to any branch.
>>
>>     which is funny <because of such and such reasons>.  Saying "because"
>>     makes it <better beause of such and such reasons>.
>>
>> I suspect that this message is about a nonsense attempt to set an
>> upstream for a detached HEAD perhaps?  Then
>>
>>     fatal: cannot set upstream for a detached HEAD
>>
>> may be shorter and more directly points at the root cause of the
>> error?
>
> I don't really understand what this code is doing.

To be honest, I didn't know what was going on at the first glance,
either.  AND I felt that it is unfair to say "when" was funny,
without understanding what it is trying to say---perhaps it may be
implying that upstream of HEAD could be set to "%s" when "it" does
point at some branch, or something, even though, as I said, "it" is
unclear without really knowing the context.

I think this "branch is NULL" condition is when an earlier call to
branch_get() returned a NULL, and _one_ way to make that happen is
to detach the HEAD.  There may be others, but I didn't check.

> This error message can be triggered by running `git branch
> --set-upstream-to=origin/master` from a detached head. But if running
> from a detached head is the only way to trigger the error message, why
> does the code use strcmp instead of if (detached) { ... } as other
> code in that function does?

The 'detached' merely is "Is the _current_ HEAD detached?", not "Is
the branch the user asked us to do something about the detached
HEAD?", I think.

If you are getting a NULL out of branch_get() but the user did
"branch -u foo thisbranch", then that is an indication that we
shouldn't be saying that "nono, detached HEAD will never have its
own upstream", because that is not what the user asked us to do.  So
"no argument (implying, we defaulted to HEAD) or the argument is
spelled HEAD" I think is the right thing to check.

And the other error message "no such branch" hints (again, I didn't
follow the codepath) that we may get a NULL in branch if you did
"git branch -u foo no-such-branch".
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]