Re: Creating own hierarchies under $GITDIR/refs ?

[Jeff King <peff@peff.net>]

On Sun, Feb 02, 2014 at 11:37:39AM +0100, David Kastrup wrote:

> So I mused: refs/heads contains branches, refs/tags contains tags.  The
> respective information would likely easily enough be stored in refs/bzr
> and refs/bugs and in that manner would not pollute the "ordinary" tag
> and branch spaces, rendering "git tag" and/or "git branch" output mostly
> unusable.  I tested creating such a directory and entries and indeed
> references like bzr/39005 then worked.

Yes. The names "refs/tags" and "refs/heads" are special by convention,
and there is no reason you cannot have other hierarchies (and indeed, we
already have "refs/notes" and "refs/remotes" as common hierarchies).

> However, cloning from the repository did not copy those directories and
> references, so without modification, this scheme would not work for
> cloned repositories.

Correct. Anyone who wants them will have to ask for them manually, like:

  git config --add remote.origin.fetch '+refs/bzr/*:refs/bzr/*'

after which any "git fetch" will retrieve them.

> Are there some measures one can take/configure in the parent repository
> such that (named or all) additional directories inside of $GITDIR/refs
> would get cloned along with the rest?

No. It is up to the client to decide which parts of the ref namespace
they want to fetch. The server only advertises what it has, and the
client selects from that.


Others mentioned that refs were never really intended to scale to
one-per-commit. We serve some repositories with tens of thousands of
refs from GitHub, and it does work. On the backend, we even have some
repos in the hundreds of thousands (but these are not client facing).
Most of the pain points (like O(n^2) loops) have been ironed out, but
the two big ones are still:

  - server ref advertisement lists _all_ refs at the start of the
    conversation. So, e.g.,

        git fetch git://github.com/Homebrew/homebrew.git

    sends 2MB of advertisement just so a client can find out "nope,
    nothing to fetch".

  - the packed-refs storage is rather monolithic. Reading a value from
    it currently requires parsing the whole file. Likewise, deleting a
    ref requires rewriting the whole file.

So what you are proposing will work, but do note that there is a cost.

-Peff