Re: reftable [v4]: new ref storage format

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 3, 2017, 02:36 UTC
Message-ID: <xmqq8tj1qswl.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAJo=hJuWc-hLyTgtdO_AYjUhvRWFSY70bBPEgNtygs5ojJcKyQ@mail.gmail.com>

Shawn Pearce <spearce@spearce.org> writes:

Show 10 quoted lines

> On Wed, Aug 2, 2017 at 6:50 PM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>>    Would it benefit us if we define the sort order of bytes slightly
>>    different from the ASCII order, so that a slash '/' sorts between
>>    NUL '\000' and SOH '\001', which is the order we should have used
>>    when storing the entries in the index?
>
> I'm not really with that. It complicates the compare routine, and
> makes the data in reftable sorted differently than we announce in the
> wire protocol.

Fair enough. It was not like I had some operations in mind that would benefit from such a sort order (i.e. walking two of these things in parallel and merging them, which would have been the case for the index when we walk it together with one or more trees); if there is no such operation that benefit, there is no reason to try to be clever here.

Show 12 quoted lines

>>  * Even though readers can continue accessing, starting from the
>>    $GIT_DIR/refs, without locking and get consistent views, any
>>    transaction that groups one or more ref updates would need to
>>    take a global lock on $GIT_DIR/refs file.
>>
>>    Would it become a problem in a busy repository?
> ...
>
> I'm not really sure how one could safely do the same thing with
> git-core. Its certainly not going to be portable or safe on NFS if we
> tried to do anything fancy with flock(2), fcntl(F_SETLKW), or
> semop(2).

Yes.

And for public record, another thing we privately discussed was that we currently do not know if we would want to make this design mesh well with the use of multiple worktrees (IIUC, HEAD and things outside refs/, and refs/bisect/, need to be per- worktree, while others are to be common), and if so how.