Re: Push force-with-lease with multi-URL remote

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 29, 2019, 05:19 UTC
Message-ID: <xmqqa7cxl8od.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <C021D654-ECD4-4A23-9DE0-D272C3A3D901@chead.ca>

Christopher Head <bugs@chead.ca> writes:

Show 7 quoted lines

> On July 27, 2019 1:57:18 PM PDT, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>>In the reverse direction, I think "git fetch" supports the notion of
>><group> of repositories, so that fetch from multiple remotes can be
>>initiated with a single command, but I am not sure if we added the
>>same <group> concept to the pushing side.
>>...

> If I understand what remote groups are (separate remotes but you
> can act on all of them with one command?) then they should be
> perfect. However it does not look like they work for
> pushing.

Yup, you are confirming what I already said ;-).

I do not offhand think of a fundamental reason why the <group> concept should only apply to the fetching direction. I am not sure about a few design issues if we were to have "push" groups, though, and somebody who wants to have the feature must think hard about.

Should the same <group> be usable for both fetching and pushing, or should there be two separate and independent namespaces, one for fetch groups and the other for push groups, so that the set of repositories "git fetch groupA" fetches from could be configured to be different from the set of repositories "git push groupA"? It can be argued for both ways, but I am unsure about the pros and cons.

How should the feature interact with push atomicity? We obviously would not want (and probably cannot afford) to arrange two or more repositories coodinate by participating in two-phase commit etc., so the best we could do may be to not even initiate push after seeing a push to one destination fail, but there may be a better definition people can come up with.