Re: Creating own hierarchies under $GITDIR/refs ?

From: David Kastrup <dak@gnu.org>
Date: Feb 2, 2014, 12:09 UTC
Message-ID: <87sis1zpf3.fsf@fencepost.gnu.org>
In-Reply-To: <CACsJy8A44EoxEb3b=ZZ-jgLLtn1ttr0P8gGwWJ2dNYCWi3MRUw@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 9 quoted lines

> On Sun, Feb 2, 2014 at 6:19 PM, David Kastrup <dak@gnu.org> wrote:
>> Since Git has a working facility for references that is catered to do
>> exactly this kind of mapping and already _does_, it seems like a
>> convenient path to explore.
>
> It will not scale. If you make those refs available for
> cloning/fetching, all of them will be advertised first thing when git
> starts negotiate. Imagine thousands of refs (and keep increasing) sent
> to the receiver at the beginning of every connection.

In current LilyPond repository:
git tag|wc
    969     969   15161

In current Emacs mirror:
git tag|wc
   1202    1202   15729

In current Git repository:
git tag|wc
    498     498    4820

> Something like "reverse git-notes" may transfer more efficiently. Or
> we need to improve git protocol to handle massive refs better,
> something that's been discussed for a while without any outcome.

I think that even disregarding special use of references, _existing_ practice would already appear to warrant being able to deal with thousands of refs in a reasonable manner.

It's a reasonable expectation to have a tag per (potentially intermediate) release or release candidate. For any project publishing reproducible daily snapshots, the threshold of 1000 will get reached within few years.

Of course, it is relevant information to know that right _now_ references will not scale. But that does not seem like a defensible long-term perspective.

-- 
David Kastrup