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

[Patrick Steinhardt <ps@pks.im>]

On Thu, Jul 24, 2025 at 11:38:35AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
[snip]
> > +	if (flags & REF_ISSYMREF) {
> > +		strbuf_addstr(&new_referent, referent);
> > +		strbuf_splice(&new_referent, strlen("refs/remotes/"), strlen(rename->old_name),
> > +			      rename->new_name, strlen(rename->new_name));
> > +		oid = NULL;
> > +	}
> > +
> > +	error = ref_transaction_delete(rename->transaction, refname,
> > +				       oid, referent, REF_NO_DEREF, NULL, rename->err);
> 
> Remove old ...
> 
> > +	if (error < 0)
> > +		goto out;
> > +
> > +	strbuf_reset(&new_refname);
> > +	strbuf_addstr(&new_refname, refname);
> > +	strbuf_splice(&new_refname, strlen("refs/remotes/"), strlen(rename->old_name),
> > +		      rename->new_name, strlen(rename->new_name));
> > +
> > +	error = ref_transaction_update(rename->transaction, new_refname.buf, oid,
> > +				       null_oid(the_hash_algo), (flags & REF_ISSYMREF) ? new_referent.buf : NULL, NULL,
> > +				       REF_SKIP_CREATE_REFLOG | REF_NO_DEREF | REF_SKIP_OID_VERIFICATION,
> > +				       NULL, rename->err);
> 
> ... and create new.  Would we be hit with the same "while renaming A
> to A/B, there is a D/F conflict which the ref transaction does not
> handle by itself" issue we saw recently here?

Yes, we do indeed. I've now split this up into two transactions that get
populated concurrently.

Patrick