Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
>> --- a/builtin/push.c
>> +++ b/builtin/push.c
>> @@ -322,7 +322,7 @@ static int push_with_options(struct transport *transport, int flags)
>> static int do_push(const char *repo, int flags)
>> {
>> int i, errs;
>> - struct remote *remote = remote_get(repo);
>> + struct remote *remote = pushremote_get(repo);
>
> "struct remote" has url and pushurl fields. What do they mean in the
> context of these two accessors? /me is confused.
>
> Is the idea that now I should not use pushurl any more, and that I
> should use pushremote_get and use url instead?
I thought the basic idea from the user-level is:
- If you have to use different URL to push to and fetch from the
logically same location (e.g. git://k.org/pub/scm/git/git.git
used for fetch, k.org:/pub/scm/git/git.git/ used for push), use
url for fetch, pushurl for push and you don't have to bother with
per-branch pushremote at all. You are logically working with the
same remote, perhaps called 'origin'.
- If you push to and fetch from logically different repositories,
(e.g. fetch from https://github.com/gitster/git, push to
github.com:artagnon/git), you may want to call your upstream
'origin' and your publishing repository 'mine'. You set the
remote.pushdefault to 'mine', perhaps like:
[remote "mine"]
url = github.com:artagnon/git
(this can also be written with remote.mine.pushurl).
By splitting remote_get() used for fetch and pushremote_get() used
for push, the latter function can return 'origin' and 'mine' for
these two cases, while remote_get() will return 'origin' for both of
these cases. At the programming level, you would still ask what the
URL to be pushed to to the remote obtained here, and would use
pushurl if defined, or url otherwise.
Ram, am I following your thoughts correctly?
--
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