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

[Usman Akinyemi <usmanakinyemi202@gmail.com>]

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.
    A follow-up could add push.parallel (mirroring fetch.parallel) to
    allow parallel pushes to group members via run_processes_parallel(),
    the same mechanism fetch uses. Feedback on whether this is
    desirable for push is welcome.

  - push.default = simple interacts poorly with group pushes when the
    current branch has no upstream set, since setup_default_push_refspecs()
    will die on the first remote that is not the upstream. Users should
    use push.default = current or explicit refspecs for group pushes.
    It is worth discussing whether the group push path should automatically
    imply push.default = current, or whether a clear error message
    directing the user to configure this would be sufficient.

  - force-with-lease semantics across a group push are currently
    unmodified — the same CAS constraints are forwarded to every remote
    in the group. Whether this is the right behaviour or whether
    per-remote lease tracking is needed is an open question.

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

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

-- 
2.53.0