Re: [PATCH v2 0/2] remote: renamed remote push tracking

Hi Harald,

On Tue, Jul 21, 2026 at 5:08 AM Harald Nordgren via GitGitGadget
[off-list ref] wrote:

Keep git status showing the push branch after remotes are renamed by finding
the configured remote with the same URL.

Changes in v3:

 * Revamp commit messages to clarify motivation.

Changes in v2:

 * Clarify that URL push destinations already work and that this change only
   restores their tracking information.
 * Document URL values for branch.<name>.pushRemote and their @{push}
   behavior.

Harald Nordgren (2):
  remote: pass repository to push tracking helper
  remote: find tracking branches for URL push destinations

 Documentation/config/branch.adoc |   2 +
 Documentation/revisions.adoc     |   3 +
 remote.c                         |  36 +++++++++--
 remote.h                         |   2 +
 t/t5505-remote.sh                | 104 +++++++++++++++++++++++++++++++
 transport.c                      |   5 +-
 6 files changed, 146 insertions(+), 6 deletions(-)


base-commit: 48bbf81c29ca9a4479ec7850fe206518682cdb2f
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2358%2FHaraldNordgren%2Fremote-resolve-url-push-tracking-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2358/HaraldNordgren/remote-resolve-url-push-tracking-v2
Pull-Request: https://github.com/git/git/pull/2358

Range-diff vs v1:

 1:  fc70895732 ! 1:  b1ac49de87 remote: pass repository to push tracking helper
     @@ Metadata
       ## Commit message ##
          remote: pass repository to push tracking helper

     -    The push tracking helper currently only needs the push remote. However,
     -    resolving a URL-valued remote requires access to the repository's list
     -    of configured remotes.
     +    The next commit needs tracking_for_push_dest() to inspect the
     +    repository's configured remotes. Pass the repository through the
     +    existing callers and mark the new parameter as unused.

     -    Pass the repository through the existing callers and mark the parameter
     -    as unused for now. This prepares the helper for that lookup without
     -    changing its behavior.
     +    No change in behavior.

          Signed-off-by: Harald Nordgren [off-list ref]

 2:  ff645b2159 ! 2:  6e924a7fec remote: resolve URL-valued push tracking remotes
     @@ Metadata
      Author: Harald Nordgren [off-list ref]

       ## Commit message ##
     -    remote: resolve URL-valued push tracking remotes
     +    remote: find tracking branches for URL push destinations

     -    A branch may name its push destination with a URL instead of a
     -    configured remote. This is useful in fork workflows, where the original
     -    remote is renamed to "upstream", the fork is added as "origin", and an
     -    existing branch.<name>.pushRemote continues to contain the fork URL.
     +    Git already accepts a repository URL as branch.<name>.pushRemote and
     +    can push to it. When a configured remote has the same URL, however,
     +    "git status" cannot show that remote's push branch.

     -    Git can still push through the anonymous remote created for that URL.
     -    However, the anonymous remote has no fetch refspec. Git therefore cannot
     -    resolve @{push} to origin/<branch> or update that remote-tracking branch
     -    after a push. The push can succeed, or report that everything is up to
     -    date, while status continues to compare against a stale tracking ref or
     -    cannot show the push branch at all.
     +    This can happen in fork workflows when the original remote is renamed
     +    to "upstream", the fork is added as "origin", and an existing
     +    pushRemote value still contains the fork URL. The URL still points to
     +    the right repository, so pushing works. However, @{push} is unavailable
     +    because Git does not connect the URL to "origin". As a result,
     +    "git status" cannot show the push branch, and an up-to-date push can
     +    leave its local tracking information stale.

I'm a bit confused about the problem scenario here: if the pushRemote
value contains a URL, then renaming a remote has nothing to do with
it, right?

And if the pushRemote value contains a remote name, then renaming the
remote should propagate there as well, right? (At least, that's my
recollection of renaming; when I have used the GitHub CLI in the past
it has worked pretty well in that case, but maybe they've changed
things recently?)

I do think the URL<->remote matching for user display is a nice touch,
so I'm not against the series! Just want to understand the problem
statement well. Maybe I should read over the test cases, or you could
suggest a "how I hit this in the real world" recipe? (Explicit
commands are easier for me than natural language in that case.)

-- 
D. Ben Knoble