Re: [PATCH] push: error out when the "upstream" semantics does not make sense

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

 



Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes:

> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>>  		die(_("You are pushing to remote '%s', which is not the "
>> -		      "upstream of your\ncurrent branch '%s'.\n"),
>> +		      "upstream of your\ncurrent branch '%s',\n"
>> +		      "without telling me to push which local branch to\n"
>> +		      " update which remote branch with."),
>
> Sounds overly complex sentence to me. "without telling me what to push"
> sounded good enough without being long, so I prefered it.

You are right; it is overly complex.

After sending the updated patch, I rewrote it again to:

    You are pushing to remote '%s', which is not the upstream of
    your current branch '%s', without telling me what to push
    to update which remote branch.

The point of Jonathan's 'refspec' and this attempt to rephrase it without
using a jargon is to make sure that the user realizes that both ends can
be specified.

> I like accompanying these messages with the way out for the user, so
> perhaps we can add stg like
>
> "To push the current branch to this remote, run:
>
>   git push <remote> <branch>
>
> "

I am afraid that the above advice is a lot worse than leaving it unsaid.

We are in no position to assume that the user wanted the "current"
semantics when we issue this message.  Otherwise, we would be better off
switching the default semantics to "current", not "upstream".  But the
working assumption in this series is that "upstream" is an improvement
over "current", no?

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