Re: `git remote rename` does not work when `refs/remotes/server/HEAD` is unborn (when right after `git remote add -m`)

From: Jeff King <peff@peff.net>
Date: Jul 24, 2025, 10:45 UTC
Message-ID: <20250724104536.GA1316505@coredump.intra.peff.net>
In-Reply-To: <CANrWfmQWa=RJnm7d3C7ogRX6Tth2eeuGwvwrNmzS2gr+eP0OpA@mail.gmail.com>

On Thu, Jul 24, 2025 at 09:59:45PM +1200, Han Jiang wrote:

Show 15 quoted lines

> What did you expect to happen? (Expected behavior)
> 
> `git symbolic-ref 'refs/remotes/server/HEAD'` outputs
> "refs/remotes/server/master";
> `git symbolic-ref 'refs/remotes/server2/HEAD'` outputs
> "refs/remotes/server2/master".
> 
> What happened instead? (Actual behavior)
> 
> `git symbolic-ref 'refs/remotes/server/HEAD'` outputs
> "refs/remotes/server/master";
> `git symbolic-ref 'refs/remotes/server2/HEAD'` outputs "fatal: ref
> refs/remotes/server2/HEAD is not a symbolic ref".
> `git symbolic-ref 'refs/remotes/server/HEAD'` outputs
> "refs/remotes/server/master".

Thanks for the report. I can reproduce the issue easily here. Probably a simpler reproduction is just:

  git init
  git remote add -m whatever server1 /does/not/need/to/exist
  git remote rename server1 server2
  git symbolic-ref refs/remotes/server2/HEAD

The problem is that the branch-renaming code in git-remote is not prepared to handle symrefs that don't resolve. This seems to make it work:

diff --git a/builtin/remote.c b/builtin/remote.c
index 5dd6cbbaee..478ea3a80c 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -630,7 +630,9 @@ static int read_remote_branches(const char *refname, const char *referent UNUSED
 	if (starts_with(refname, buf.buf)) {
 		item = string_list_append(rename->remote_branches, refname);
 		symref = refs_resolve_ref_unsafe(get_main_ref_store(the_repository),
-						 refname, RESOLVE_REF_READING,
+						 refname,
+						 RESOLVE_REF_READING |
+						 RESOLVE_REF_NO_RECURSE,
 						 NULL, &flag);
 		if (symref && (flag & REF_ISSYMREF)) {
 			item->util = xstrdup(symref);
@@ -835,8 +837,8 @@ static int mv(int argc, const char **argv, const char *prefix,
 	 * First remove symrefs, then rename the rest, finally create
 	 * the new symrefs.
 	 */
-	refs_for_each_ref(get_main_ref_store(the_repository),
-			  read_remote_branches, &rename);
+	refs_for_each_rawref(get_main_ref_store(the_repository),
+			     read_remote_branches, &rename);
 	if (show_progress) {
 		/*
 		 * Count symrefs twice, since "renaming" them is done by

That is, we need two fixes:

  1. When iterating over the refs, we need to cover _all_ refs, not just
     those that fully resolve (there's a related bug here: we'll
     silently ignore an actual broken or corrupt ref, whereas I think
     the right thing would probably be to try copying it and then
     complain loudly if we don't have the object).

  2. When resolving each one, we shouldn't recurse. We're doing a
     shallow copy, not a deep one.

Reading this code, though, I can't help but think that the recent "git
refs migrate" command had to deal with all of these problems. I wonder
if we could reuse its code. +cc pks for wisdom.

-Peff

PS I think there's a related bug. If we have a real upstream repo and
   try to "git fetch" with HEAD pointing to the unborn state, it will be
   overwritten! I think this is the remote.*.followRemoteHEAD logic
   being overly zealous in "create" mode. It should probably leave an
   existing value alone, even if it points to an unborn branch.