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.


I suspect the REF_ISRENAME flag shouldn't be needed.  Wouldn't
something like the following work (in _commit)?

        Allocate work space
        Copy sort, and reject duplicate refs
        Acquire all locks while verifying old values
                This calls is_refname_available.
                If a refname is unavailable, goto slowpath.
        Perform updates first so live commits remain referenced.
        Perform deletes now that updates are safely completed.

        Acquire locks, telling is_refname_available not to worry
                about deleted refs.
        Lock packed-refs.
        Add all relevant refs to packed-refs (pack_if_possible_fn).
        Commit packed-refs.
        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.
        Release locks.

This wouldn't be any slower for the case without D/F conflicts, and in
the D/F conflict case, it should work for arbitrary transactions
that want to remove one ref to make room for another.
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