Jeff King <peff@xxxxxxxx> writes:
>> + if (strcmp(branch->remote_name, remote->name)) {
>> + struct remote *branch_dest = remote_get(branch->remote_name);
>> + const char **branch_dest_url, **dest_url;
>> +
>> + if (!push_url_of_remote(remote, &dest_url) ||
>> + !push_url_of_remote(branch_dest, &branch_dest_url) ||
>> + strcmp(dest_url[0], branch_dest_url[0]))
>> + die(_("You are pushing to remote '%s', which is not the "
>> + "upstream of your\ncurrent branch '%s'.\n"),
>> + remote->name, branch->name);
>> + }
>
> Hmm. So this will actually detect "git push $URL" when $URL matches the
> remote's configured URL. I feel like this distinction has come up
> before, and we decided not to equate the two. But now I can't remember
> where (maybe it when fetching via URL versus via remote?).
>
> What should happen if there are multiple push URLs configured?
This is me merely try to be extra nice without succeeding.
Perhaps it was an ill-thought-out part of the patch. The reasoning was
that when you know that your 'origin' is at $URL, it might be irritating
if "git push $URL" did not do what "git push origin" did, but we can
always say 'origin' that is a remoteo nickname is different from $URL; a
remote nickname does not have to be _only_ substitute of the URL, but it
can do more for you. That would give you more incentive to define remotes
that you interact with often, while keeping the bare-metal flexibility
when interacting with other remotes in a one-shot fashion.
I personally would be perfectly fine if
$ git push $URL
that does not say what to push out how, regardless of push.default
settings, errors out.
The same can be said when a remote has more than one URL to be pushed to.
Personally I do not care too much about it, but this is one more reason
not to support "upstream" over "current" as the default setting.
--
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