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?

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to