On Thu, May 22, 2014 at 4:53 PM, Jonathan Nieder <jrnie...@gmail.com> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html