Hi Harald,

On Tue, Jul 21, 2026 at 5:08 AM Harald Nordgren via GitGitGadget
<gitgitgadget@gmail.com> 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 <haraldnordgren@gmail.com>
>
>  2:  ff645b2159 ! 2:  6e924a7fec remote: resolve URL-valued push tracking remotes
>      @@ Metadata
>       Author: Harald Nordgren <haraldnordgren@gmail.com>
>
>        ## 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

It's very valid and I need to explain it better if you are confused.



Harald

> Le 21 juil. 2026 à 16:14, Harald Nordgren via GitGitGadget <gitgitgadget@gmail.com> a écrit :
> 
> Fix git status not showing the push branch after remotes are renamed, when
> branch.<name>.pushRemote is a URL matching exactly one configured remote.
> 
> Changes in v4:
> 
> * Match against the actual push URL, including pushurl and pushInsteadOf.
> * Clarify how rearranging remotes exposes the git status tracking problem.
> * Simplify and correct the documentation for URL-valued pushRemote.
> 
> 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 |   1 +
> Documentation/revisions.adoc     |   3 +
> remote.c                         |  43 +++++++++--
> remote.h                         |   2 +
> t/t5505-remote.sh                | 124 +++++++++++++++++++++++++++++++
> transport.c                      |   5 +-
> 6 files changed, 172 insertions(+), 6 deletions(-)
> 
> 
> base-commit: 48bbf81c29ca9a4479ec7850fe206518682cdb2f
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2358%2FHaraldNordgren%2Fremote-resolve-url-push-tracking-v3
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2358/HaraldNordgren/remote-resolve-url-push-tracking-v3
> Pull-Request: https://github.com/git/git/pull/2358
> 
> Range-diff vs v2:
> 
> 1:  b1ac49de87 = 1:  b1ac49de87 remote: pass repository to push tracking helper
> 2:  6e924a7fec ! 2:  a343af9d50 remote: find tracking branches for URL push destinations
>     @@ Metadata
>       ## Commit message ##
>          remote: find tracking branches for URL push destinations
> 
>     -    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 accepts a repository URL as branch.<name>.pushRemote and can push
>     +    to it. This branch setting takes precedence over remote.pushDefault.
> 
>     -    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,
>     +    A branch can be configured with a URL-valued pushRemote before any push
>     +    occurs. If the remotes are later rearranged with "git remote rename" and
>     +    "git remote add", the newly added remote may use that URL. The URL value
>     +    is unaffected by the rename and continues to take precedence over
>     +    remote.pushDefault. The URL and the remote then point to the same
>     +    repository, but Git does not connect them for tracking. Pushing works,
>     +    but @{push} cannot identify the remote's tracking branch. As a result,
>          "git status" cannot show the push branch, and an up-to-date push can
>     -    leave its local tracking information stale.
>     +    leave its tracking information stale.
> 
>     -    When exactly one configured remote has the URL as one of its
>     -    remote.<name>.url values, use its fetch refspec to find and refresh the
>     -    push branch. Keep the URL as the push destination so the configured
>     -    remote's push settings do not change existing behavior. Keep the
>     -    current behavior when no remote matches or multiple remotes match.
>     +    When exactly one configured remote uses the push destination URL, use
>     +    that remote for push tracking. Continue to push to the URL so the
>     +    configured remote's push settings do not change existing behavior. Keep
>     +    the current behavior when no remote matches or multiple remotes match.
> 
>          Signed-off-by: Harald Nordgren <haraldnordgren@gmail.com>

I find this explanation makes more sense ; it’s not how I use remote renames, since I don’t usually use URL-valued remotes, but I can see how things arise now. Thanks!

"Harald Nordgren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> Fix git status not showing the push branch after remotes are renamed, when
> branch.<name>.pushRemote is a URL matching exactly one configured remote.
>
> Changes in v4:
>
>  * Match configured remotes by effective push URL, preferring pushurl over
>    url.
>  * Update the documentation and rationale to describe where the remote would
>    push.

My cursory review did not spot anything obviously wrong anymore.

As it somehow seems to be a slow week, I do not expect to see many
eyeballs from others helping to review the topics in flight as
quickly as we would have liked to move them forward, though.

Thanks.