Re: [RFC PATCH 2/2] push: support pushing to a remote group

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 9, 2026, 13:38 UTC
Message-ID: <xmqqzf4h6s3b.fsf@gitster.g>
In-Reply-To: <CAPSxiM_KVU7rE49=omWUwaYS-u_J6eQPDgTRjPop1gj6BM1qKQ@mail.gmail.com>

Usman Akinyemi <usmanakinyemi202@gmail.com> writes:

Show 20 quoted lines

> Also, in the cover letter, I asked some questions. I think you might
> have missed it.
>
> Quoting here again:
> "
>   - 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 want feedback on this also.

Quite honestly, I do not have strong opinions on either of these points, primarily because the answer would become self evident if we follow a simple general principle to explain this feature to end users, which is:

When you have N remotes r1, r2, ..., rN, and a remote group G that expands (possibly recursively) to these N remotes, then for any and all values of $options and $args, this command invocation

    $ git push $options G $args

should mean exactly the same thing as

    $ git push $options r1 $args
    $ git push $options r2 $args
    ...
    $ git push $options rN $args

So the answer to the first one would be:

    "git push r1" (without any other parameters) may work while "git
    push r2" (the same, wihtout any other parameters) may fail,
    depending on how the push.default is set and on what branch you
    run these two pushes.  "git push G" should behave the same way.
    There is nothing extra fancy needs to be done.  If the user
    wants to push to these N remotes as a whole in an identical way
    by using remote group G, they are the one who is responsible to
    make this sequences of pushes "git push r1; git push r2; ..."
    make sense.

The answer to the second one would be derived the same way. If $options includes the "--force-with-lease=<commit>", then the command should behave as if copies of the command that pushes to these N remotes, "git push --force-with-lease=<commit> r$i", are invoked. If <commit> is not given (which is not a recommended even for pushes to a single remote, because with background fetching, guesses based on the remote-tracking branches are never be reliable), the command may guess what commit to expect on the remote the same way as if these N independent pushes are made without using group feature (which of course may make different guesses for each remote, if their remote-tracking branches are pointing at different commits).