From: Junio C Hamano Date: Mon, 28 Jul 2025 18:57:07 GMT Subject: Re: [PATCH 3/4] builtin/remote: rework how remote refs get renamed Message-ID: In-Reply-To: Justin Tobler 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.