From: D. Ben Knoble Date: Wed, 28 Oct 2026 22:24:51 GMT Subject: Re: [PATCH] remote: resolve "simple" @{push} when pushing to another remote Message-ID: In-Reply-To: On Tue, Oct 27, 2026 at 8:48 AM Harald Nordgren via GitGitGadget wrote: > > From: Harald Nordgren > > With push.default left at "simple", a branch whose upstream is on one > remote and whose push remote is another gets pushed by "git push" to a > branch of the same name on the push remote. But @{push} for that > branch fails with "cannot resolve 'simple' push to a single > destination". At first I was a bit confused about the need for a different push remote, but then I realized: simple's documentation says that if the push and pull remote are the *same* you need the upstream to have the same name! So in the differing case, it might behave quite differently than I'm used to. > "git push" learned to handle "simple" this way in ed2b18292b (push: > change `simple` to accommodate triangular workflows, 2013-06-19). When > @{push} was added in e291c75a95 (remote.c: add branch_get_push, > 2015-05-21), its "simple" case only covered pushing back to the remote > the branch is fetched from, where the upstream must have the same name. > > Make @{push} follow "git push". When the push remote is not the remote > of the branch, resolve to the branch of the same name on the push > remote, as "current" does. Whatever else we do, making @{push} work in more scenarios seems good to me so we can be consistent. > The test added in 9bf9eed093 (remote: fix leak in branch_get_push_1() > with invalid "simple" config, 2026-01-19) relied on a different push > remote being invalid for "simple". Use an upstream with a different > name on the same remote instead, so that it still exercises the error > path. > > Signed-off-by: Harald Nordgren > --- > remote: resolve "simple" @{push} when pushing to another remote > > With push.default=simple and remote.pushDefault pointing at a fork, git > push pushes the branch to the fork, but @{push} fails with "cannot > resolve 'simple' push to a single destination". > > So git status cannot compare the branch with where it was pushed. Make > @{push} resolve to where git push goes. > > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2466%2FHaraldNordgren%2Fat-push-simple-triangular-v1 > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2466/HaraldNordgren/at-push-simple-triangular-v1 > Pull-Request: https://github.com/git/git/pull/2466 > > remote.c | 4 ++++ > t/for-each-ref-tests.sh | 4 +++- > t/t1514-rev-parse-push.sh | 11 +++++++++++ > 3 files changed, 18 insertions(+), 1 deletion(-) > > diff --git a/remote.c b/remote.c > index 49ee2ea318..fd434a3a10 100644 > --- a/remote.c > +++ b/remote.c > @@ -2016,6 +2016,10 @@ static char *branch_get_push_1(struct repository *repo, > const char *up; > char *cur; > > + if (strcmp(remote->name, > + remotes_remote_for_branch(remote_state, branch, NULL))) > + return tracking_for_push_dest(repo, remote, branch->refname, err); This certainly matches the logic described in the log message, and I think it's probably right based on that description. One thing I can't decide is whether it should come before or after the current set of cases, and I'm undecided. On one hand, it's a new case, so I would think it should come after. OTOH, it's a fairly straightforward case, and I usually like discharging those early so I can focus on the complex stuff. So, I would say this is probably fine as-is? [Skipping the tests for now]