From: Ronnie Sahlberg <sahlberg@google.com>
Date: Fri, 23 May 2014 14:59:21 GMT
Subject: Re: [PATCH v8 41/44] refs.c: add a new flag for transaction delete for refs we know are packed only
Message-ID: <CAL=YDWnRkwX3dCv9dyZmBdh2ZV7aSUCS=F6w67gJuBmCzGGBwQ@mail.gmail.com>
In-Reply-To: <20140522235351.GB12314@google.com>

On Thu, May 22, 2014 at 4:53 PM, Jonathan Nieder <jrnieder@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.



>
> Thanks,
> Jonathan