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? 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