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

[Junio C Hamano <gitster@pobox.com>]

Justin Tobler <jltobler@gmail.com> writes:

>> +	 * 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.