Re: Creating own hierarchies under $GITDIR/refs ?

[David Kastrup <dak@gnu.org>]

Duy Nguyen <pclouds@gmail.com> writes:

> 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