Re: [PATCH 3/4] builtin/remote: rework how remote refs get renamed

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 28, 2025, 18:57 UTC
Message-ID: <xmqqjz3suosc.fsf@gitster.g>
In-Reply-To: <j75h4trgwn5dvvxy6cqjv6pbh5ernehvnoi5itqr3icogebegp@ldbsvfwtxoeo>

Justin Tobler <jltobler@gmail.com> writes:

Show 12 quoted lines

>> +	 * This split is required to avoid conflicting ref updates when a
>> +	 * remote is being nested into itself or converted into its parent
>> +	 * directory.
>> +	 *
>> +	 * Unfortunately this means that the operation isn't atomic. But we
>> +	 * cannot avoid that, unless transactions learn to handle such
>> +	 * conflicts one day.
>>  	 */
>
> We could detect if the rename operation would result in a D/F conflict
> upfront and special case it by using two transactions. If we know there
> isn't a D/F conflict, I think a single transaction would be sufficient.

The right solution should be at the implementation of the transactions, not the application that uses the transaction mechanism, no? So I would think the above workaround is actually counter-productive.

> That being said, it might be best to keep it simple for now and leave it
> as-is.

Yes, we do not have to update the transaction layer to fix that D/F thing in this same series.

Thanks.