Junio C Hamano wrote:
> Jonathan Nieder <jrnie...@gmail.com> writes:
>>> - 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?
[...]
> 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.
Ah, I think I see. It might be more convenient to the caller if
pushremote_get returned a remote with url set to the pushurl, but
that would prevent sharing the struct with other callers that want
that remote for fetching.
So instead, the idea is something like
remote: support a different default remote for pushing
Teach remote_get() to accept an argument FOR_FETCH or FOR_PUSH
that determines, when no remote is passed to it, whether to use
the default remote for fetching or the default for pushing.
The default remote for fetching is stored in the static var
"default_remote_name", while the default for pushing, if set,
is in "default_push_remote_name".
Currently there is never a different default for pushing set
but later patches will change that.
If remote_get() gained a new required parameter, that would force all
call sites to be examined (even any potential call sites added by new
patches in flight) and there would no longer be need for the
remote_get_1() function.
What do you think?
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
