On Thu, Jul 24, 2025 at 11:38:35AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@xxxxxx> 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
