On Thu, May 22, 2014 at 4:53 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Jonathan Nieder wrote: >> Ronnie Sahlberg wrote: > >>> I hate rename_ref :-) >>> >>> I have reworked the transaction code to special case the deletion of >>> the old ref for n/n -> n and n -> n/n renames >>> so that we can carefully avoid n/n.lock files to exist or prevent the >>> directory <-> file transition for n during these renames. > [...] >> Unlink the corresponding loose refs so packed-refs >> becomes authoritative for them. >> Lock packed-refs. >> Perform updates and removals in the packed-refs cache. >> Commit packed-refs. > > ... or is the problem that the reflogs conflict? > > How does rename_ref handle propagating the reflog from the old > name to the new name, by the way? I haven't touched that yet, but we can fix it after the next series when we have transaction support for reflogs. It still renames the reflog via the magic name #define TMP_RENAMED_LOG "logs/refs/.tmp-renamed-log" and thus, if you run two renames at the same time there is a race that might make you end up with the wrong reflog after the rename. > > Thanks, > Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html