Justin Tobler <jltobler@xxxxxxxxx> 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.
