Re: [PATCHv2 1/2] Support multiple virtual repositories with a single object store and refs

[Junio C Hamano <gitster@pobox.com>]

Jamey Sharp <jamey@minilop.net> writes:

> Given many repositories with copies of the same objects (such as
> branches of the same source), sharing a common object store will avoid
> duplication.  Alternates provide a single baseline, but don't handle
> ongoing activity in the various repositories.  Git safely handles
> concurrent accesses to the same object store across repositories, but
> operations such as gc need to know about all of the refs.
>
> This change adds support in upload-pack and receive-pack to simulate
> multiple virtual repositories within the object store and references of

Is it just me to read the above and then have to re-read the first
sentence of the second paragraph over and over again?  There seems to be a
huge gap in logic flow, probably largely due to the use of undefined term
"virtual repository".

I think the idea is "an object store .git/objects/ may have more objects
than the refs .git/refs/* in the repository that particular object store
belongs to, and it is unsafe to gc there" (the first paragraph), and then
what is left unsaid is "to solve it, we propose to add an extra namespace
in the refs hierarchy of such a repository that lets other repositories to
borrow its objects from, and store the tips of refs of the borrowing
repository there (and call such a repository that lets others borrow a
virtual repository)" or something.

Without presenting what you are trying to solve...

> a single underlying repository.  The refs and heads of the virtual
> repositories get stored in the underlying repository using prefixed
> names specified by the --ref-prefix and --head options; for instance,
> --ref-prefix=repo1/ will use refs/repo1/heads/* and refs/repo1/tags/*.
> upload-pack and receive-pack will not expose any references that do not
> match the specified prefix.
>
> These options implement the underlying mechanism for virtual
> repositories; the higher-level protocol handler (such as http-backend or
> a custom server) can pass these options when invoking upload-pack or
> receive-pack, providing values based on components of the repository
> path.

... these are just gibberish describing technical details at too low-level.

> For a simple local test, git-remote-ext works:
>
> git clone ext::'git %s --ref-prefix=prefix/ --head=prefix-HEAD /tmp/prefixed.git'
>
> Commit by Josh Triplett and Jamey Sharp.

Have a blank line here, as that line is not part of Sign-of chain.

> Signed-off-by: Josh Triplett <josh@joshtriplett.org>
> Signed-off-by: Jamey Sharp <jamey@minilop.net>

> Cc: Shawn O. Pearce <spearce@spearce.org>
> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Cc: Johannes Sixt <johannes.sixt@telecom.at>

Also personally I do not appreciate seeing Cc: here. You already have them
at the header of your e-mail; these lines belong there, not here.

I haven't looked deeply at the patch yet.