Re: [PATCH 4/6] remote.c: introduce a way to have different remotes for fetch/push

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mar 22, 2013, 23:41 UTC
Message-ID: <20130322234108.GL12223@google.com>
In-Reply-To: <7vli9f5bho.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

> Jonathan Nieder <jrnieder@gmail.com> writes:

Show 8 quoted lines

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