Re: [RFC PATCH v2 0/2] push: add support for pushing to remote groups

[Junio C Hamano <gitster@pobox.com>]

Usman Akinyemi <usmanakinyemi202@gmail.com> writes:

> This RFC series adds support for `git push` to accept a remote group
> name (as configured via `remotes.<name>` in config) in addition to a
> single remote name, mirroring the behaviour that `git fetch` has
> supported for some time.
>
> A user with multiple remotes configured as a group can now do:
>
>     git push all-remotes
>
> instead of pushing to each remote individually, in the same way that:
>
>     git fetch all-remotes
>
> already works.
>
> The series is split into two patches:
>
>   - Patch 1 moves `get_remote_group`, `add_remote_or_group`, and the
>     `remote_group_data` struct out of builtin/fetch.c and into
>     remote.c/remote.h, making them part of the public remote API.
>
>   - Patch 2 extends builtin/push.c to use the newly public
>     `add_remote_or_group()` to resolve the repository argument as
>     either a single remote or a group, and pushes to each member of
>     the group in turn.
>
> RFC notes and open questions:

>   - The current implementation pushes to group members sequentially.
>   - push.default = simple interacts poorly with group pushes when the
>   - force-with-lease semantics across a group push are currently

I am indifferent; comments from others very much welcomed.

>
>   - I will also add the tests and documentations in the next iterations

Hmm, is this still valid?

> Changes in v2:
>   - Remove UNUSED from the declaration in remote.h (patch 1).
>   - Drop the persistent `remote` variable from cmd_push entirely
>     (patch 2). Following Junio's suggestion, the default remote
>     case now folds into remote_group so the single-remote and
>     group cases are handled by a single unified loop. There is
>     no longer any structural difference between pushing to one
>     remote and pushing to a group — a singleton is just a group
>     of one.
>   - Move the --mirror+refspec and --all+refspec conflict checks
>     inside the loop so they are evaluated per remote.
>   - Add a URL/path fallback so that direct path arguments like
>       git push /tmp/foo.git
>     continue to work correctly after the remote resolution
>     change.
>   - Add a test script t5528-push-group.sh covering the new
>     group push behaviour.

I think you added 5566 instead of 5528 (the latter of which is
already used by another test).

>   - Update Documentation/git-push.adoc: DESCRIPTION, the
>     <repository> argument description, and a new REMOTE GROUPS
>     section documenting the defining principle that
>       git push <options> all-remotes <args>
>     is exactly equivalent to running git push <options> r$i <args>
>     for each member remote independently.
>
>
> Usman Akinyemi (2):
>   remote: move remote group resolution to remote.c
>   push: support pushing to a remote group
>
>  Documentation/git-push.adoc |  76 +++++++++++++++++++---
>  builtin/fetch.c             |  42 ------------
>  builtin/push.c              | 124 ++++++++++++++++++++++++++----------
>  remote.c                    |  37 +++++++++++
>  remote.h                    |  12 ++++
>  t/meson.build               |   1 +
>  t/t5566-push-group.sh       |  95 +++++++++++++++++++++++++++
>  7 files changed, 303 insertions(+), 84 deletions(-)
>  create mode 100755 t/t5566-push-group.sh