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

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

[Jamey Sharp]

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
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.  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.
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>
---
v2: remove accidentally-included debug message; and add patch 2/2 for
    git-http-backend.

 builtin/receive-pack.c |   36 +++++++++++++++++++++++++++---------
 upload-pack.c          |   34 +++++++++++++++++++++++++++-------
 2 files changed, 54 insertions(+), 16 deletions(-)

diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index e1ba4dc..76dacd0 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -34,6 +34,8 @@ static int prefer_ofs_delta = 1;
 static int auto_update_server_info;
 static int auto_gc = 1;
 static const char *head_name;
+static const char *head_path = "HEAD";
+static const char *ref_prefix = "refs/";
 static int sent_capabilities;
 
 static enum deny_action parse_deny_action(const char *var, const char *value)
@@ -108,11 +110,12 @@ static int receive_pack_config(const char *var, const char *value, void *cb)
 
 static int show_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data)
 {
+	const char *refnameprefix = cb_data;
 	if (sent_capabilities)
-		packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
+		packet_write(1, "%s %s%s\n", sha1_to_hex(sha1), refnameprefix, path);
 	else
-		packet_write(1, "%s %s%c%s%s\n",
-			     sha1_to_hex(sha1), path, 0,
+		packet_write(1, "%s %s%s%c%s%s\n",
+			     sha1_to_hex(sha1), refnameprefix, path, 0,
 			     " report-status delete-refs side-band-64k",
 			     prefer_ofs_delta ? " ofs-delta" : "");
 	sent_capabilities = 1;
@@ -121,9 +124,9 @@ static int show_ref(const char *path, const unsigned char *sha1, int flag, void
 
 static void write_head_info(void)
 {
-	for_each_ref(show_ref, NULL);
+	for_each_ref_in(ref_prefix, show_ref, "refs/");
 	if (!sent_capabilities)
-		show_ref("capabilities^{}", null_sha1, 0, NULL);
+		show_ref("capabilities^{}", null_sha1, 0, "");
 
 }
 
@@ -332,6 +335,8 @@ static void refuse_unconfigured_deny_delete_current(void)
 static const char *update(struct command *cmd)
 {
 	const char *name = cmd->ref_name;
+	struct strbuf prefixed_name_buf = STRBUF_INIT;
+	const char *prefixed_name;
 	unsigned char *old_sha1 = cmd->old_sha1;
 	unsigned char *new_sha1 = cmd->new_sha1;
 	struct ref_lock *lock;
@@ -342,7 +347,10 @@ static const char *update(struct command *cmd)
 		return "funny refname";
 	}
 
-	if (is_ref_checked_out(name)) {
+	strbuf_addf(&prefixed_name_buf, "%s%s", ref_prefix, name + 5);
+	prefixed_name = strbuf_detach(&prefixed_name_buf, NULL);
+
+	if (is_ref_checked_out(prefixed_name)) {
 		switch (deny_current_branch) {
 		case DENY_IGNORE:
 			break;
@@ -370,7 +378,7 @@ static const char *update(struct command *cmd)
 			return "deletion prohibited";
 		}
 
-		if (!strcmp(name, head_name)) {
+		if (!strcmp(prefixed_name, head_name)) {
 			switch (deny_delete_current) {
 			case DENY_IGNORE:
 				break;
@@ -426,14 +434,14 @@ static const char *update(struct command *cmd)
 			rp_warning("Allowing deletion of corrupt ref.");
 			old_sha1 = NULL;
 		}
-		if (delete_ref(name, old_sha1, 0)) {
+		if (delete_ref(prefixed_name, old_sha1, 0)) {
 			rp_error("failed to delete %s", name);
 			return "failed to delete";
 		}
 		return NULL; /* good */
 	}
 	else {
-		lock = lock_any_ref_for_update(name, old_sha1, 0);
+		lock = lock_any_ref_for_update(prefixed_name, old_sha1, 0);
 		if (!lock) {
 			rp_error("failed to lock %s", name);
 			return "failed to lock";
@@ -760,6 +768,16 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
 				advertise_refs = 1;
 				continue;
 			}
+			if (!prefixcmp(arg, "--head=")) {
+				head_path = arg+7;
+				continue;
+			}
+			if (!prefixcmp(arg, "--ref-prefix=")) {
+				struct strbuf prefixbuf = STRBUF_INIT;
+				strbuf_addf(&prefixbuf, "refs/%s", arg+13);
+				ref_prefix = strbuf_detach(&prefixbuf, NULL);
+				continue;
+			}
 			if (!strcmp(arg, "--stateless-rpc")) {
 				stateless_rpc = 1;
 				continue;
diff --git a/upload-pack.c b/upload-pack.c
index ce5cbbe..a1e495f 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -34,6 +34,8 @@ static int shallow_nr;
 static struct object_array have_obj;
 static struct object_array want_obj;
 static struct object_array extra_edge_obj;
+static const char *head_path = "HEAD";
+static const char *ref_prefix = "";
 static unsigned int timeout;
 /* 0 for no sideband,
  * otherwise maximum packet size (up to 65520 bytes).
@@ -640,17 +642,18 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
 	static const char *capabilities = "multi_ack thin-pack side-band"
 		" side-band-64k ofs-delta shallow no-progress"
 		" include-tag multi_ack_detailed";
+	const char *refnameprefix = cb_data;
 	struct object *o = parse_object(sha1);
 
 	if (!o)
 		die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
 
 	if (capabilities)
-		packet_write(1, "%s %s%c%s%s\n", sha1_to_hex(sha1), refname,
+		packet_write(1, "%s %s%s%c%s%s\n", sha1_to_hex(sha1), refnameprefix, refname,
 			     0, capabilities,
 			     stateless_rpc ? " no-done" : "");
 	else
-		packet_write(1, "%s %s\n", sha1_to_hex(sha1), refname);
+		packet_write(1, "%s %s%s\n", sha1_to_hex(sha1), refnameprefix, refname);
 	capabilities = NULL;
 	if (!(o->flags & OUR_REF)) {
 		o->flags |= OUR_REF;
@@ -659,7 +662,7 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
 	if (o->type == OBJ_TAG) {
 		o = deref_tag(o, refname, 0);
 		if (o)
-			packet_write(1, "%s %s^{}\n", sha1_to_hex(o->sha1), refname);
+			packet_write(1, "%s %s%s^{}\n", sha1_to_hex(o->sha1), refnameprefix, refname);
 	}
 	return 0;
 }
@@ -678,15 +681,24 @@ static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag
 
 static void upload_pack(void)
 {
+	struct strbuf prefix = STRBUF_INIT;
+	unsigned char sha1[20];
+	int flag;
+
+	strbuf_addf(&prefix, "refs/%s", ref_prefix);
 	if (advertise_refs || !stateless_rpc) {
 		reset_timeout();
-		head_ref(send_ref, NULL);
-		for_each_ref(send_ref, NULL);
+		if (resolve_ref(head_path, sha1, 1, &flag))
+			send_ref("HEAD", sha1, flag, "");
+		for_each_ref_in(prefix.buf, send_ref, "refs/");
 		packet_flush(1);
 	} else {
-		head_ref(mark_our_ref, NULL);
-		for_each_ref(mark_our_ref, NULL);
+		if (resolve_ref(head_path, sha1, 1, &flag))
+			mark_our_ref("HEAD", sha1, flag, NULL);
+		for_each_ref_in(prefix.buf, mark_our_ref, NULL);
 	}
+	strbuf_release(&prefix);
+
 	if (advertise_refs)
 		return;
 
@@ -716,6 +728,14 @@ int main(int argc, char **argv)
 			advertise_refs = 1;
 			continue;
 		}
+		if (!prefixcmp(arg, "--head=")) {
+			head_path = arg+7;
+			continue;
+		}
+		if (!prefixcmp(arg, "--ref-prefix=")) {
+			ref_prefix = arg+13;
+			continue;
+		}
 		if (!strcmp(arg, "--stateless-rpc")) {
 			stateless_rpc = 1;
 			continue;
-- 
1.7.5.1

[PATCHv2 2/2] Support virtual repositories in smart http-backend, specified by environment

[Jamey Sharp]

Translate the GIT_REF_PREFIX and GIT_HEAD environment variables to the
--ref-prefix= and --head= options to upload-pack and receive-pack.

Add documentation, including a sample Apache configuration snippet.

Commit by Josh Triplett and Jamey Sharp.
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>
---
v2: add patch 2/2 for git-http-backend.

 Documentation/git-http-backend.txt |   14 ++++++++++++
 http-backend.c                     |   39 +++++++++++++++++++++++++++++------
 2 files changed, 46 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index 277d9e1..4e0b243 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -119,6 +119,14 @@ ScriptAliasMatch \
 
 ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
 ----------------------------------------------------------------
++
+To serve multiple virtual repositories from a single storage
+repository:
++
+----------------------------------------------------------------
+SetEnvIf Request_URI "^/git/([^/]*)" GIT_REF_PREFIX=$1/ GIT_HEAD=$1-HEAD
+ScriptAliasMatch ^/git/[^/]*(.*) /usr/libexec/git-core/git-http-backend/storage.git$1
+----------------------------------------------------------------
 
 Accelerated static Apache 2.x::
 	Similar to the above, but Apache can be used to return static
@@ -167,6 +175,12 @@ The GIT_HTTP_EXPORT_ALL environmental variable may be passed to
 'git-http-backend' to bypass the check for the "git-daemon-export-ok"
 file in each repository before allowing export of that repository.
 
+The GIT_REF_PREFIX and GIT_HEAD environment variables allow
+http-backend to support multiple virtual repositories within a single
+storage repository.  If set, 'git http-backend' will operate on
+'refs/${GIT_REF_PREFIX}' rather than 'refs/', and '$GIT_HEAD' rather
+than HEAD.
+
 The backend process sets GIT_COMMITTER_NAME to '$REMOTE_USER' and
 GIT_COMMITTER_EMAIL to '$\{REMOTE_USER}@http.$\{REMOTE_ADDR\}',
 ensuring that any reflogs created by 'git-receive-pack' contain some
diff --git a/http-backend.c b/http-backend.c
index 8501504..3d9e3b1 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -315,16 +315,23 @@ done:
 	close(out);
 }
 
-static void run_service(const char **argv)
+#define RUN_SERVICE_LAST_EXTRA_ARG 2
+#define RUN_SERVICE_EXTRA_ARGS NULL, NULL, NULL
+
+static void run_service(const char *argv0, const char **argv)
 {
 	const char *encoding = getenv("HTTP_CONTENT_ENCODING");
 	const char *user = getenv("REMOTE_USER");
 	const char *host = getenv("REMOTE_ADDR");
+	char *ref_prefix = getenv("GIT_REF_PREFIX");
+	char *head = getenv("GIT_HEAD");
 	char *env[3];
 	struct strbuf buf = STRBUF_INIT;
 	int gzipped_request = 0;
 	struct child_process cld;
 
+	argv += RUN_SERVICE_LAST_EXTRA_ARG;
+
 	if (encoding && !strcmp(encoding, "gzip"))
 		gzipped_request = 1;
 	else if (encoding && !strcmp(encoding, "x-gzip"))
@@ -343,6 +350,24 @@ static void run_service(const char **argv)
 	env[1] = strbuf_detach(&buf, NULL);
 	env[2] = NULL;
 
+	if (ref_prefix && !*ref_prefix)
+		ref_prefix = NULL;
+	if (ref_prefix) {
+		strbuf_addf(&buf, "--ref-prefix=%s", ref_prefix);
+		ref_prefix = strbuf_detach(&buf, NULL);
+		*argv-- = ref_prefix;
+	}
+
+	if (head && !*head)
+		head = NULL;
+	if (head) {
+		strbuf_addf(&buf, "--head=%s", head);
+		head = strbuf_detach(&buf, NULL);
+		*argv-- = head;
+	}
+
+	*argv = argv0;
+
 	memset(&cld, 0, sizeof(cld));
 	cld.argv = argv;
 	cld.env = (const char *const *)env;
@@ -362,6 +387,8 @@ static void run_service(const char **argv)
 		exit(1);
 	free(env[0]);
 	free(env[1]);
+	free(ref_prefix);
+	free(head);
 	strbuf_release(&buf);
 }
 
@@ -391,7 +418,7 @@ static void get_info_refs(char *arg)
 	hdr_nocache();
 
 	if (service_name) {
-		const char *argv[] = {NULL /* service name */,
+		const char *argv[] = {RUN_SERVICE_EXTRA_ARGS,
 			"--stateless-rpc", "--advertise-refs",
 			".", NULL};
 		struct rpc_service *svc = select_service(service_name);
@@ -404,8 +431,7 @@ static void get_info_refs(char *arg)
 		packet_write(1, "# service=git-%s\n", svc->name);
 		packet_flush(1);
 
-		argv[0] = svc->name;
-		run_service(argv);
+		run_service(svc->name, argv);
 
 	} else {
 		select_getanyfile();
@@ -462,7 +488,7 @@ static void check_content_type(const char *accepted_type)
 
 static void service_rpc(char *service_name)
 {
-	const char *argv[] = {NULL, "--stateless-rpc", ".", NULL};
+	const char *argv[] = {RUN_SERVICE_EXTRA_ARGS, "--stateless-rpc", ".", NULL};
 	struct rpc_service *svc = select_service(service_name);
 	struct strbuf buf = STRBUF_INIT;
 
@@ -478,8 +504,7 @@ static void service_rpc(char *service_name)
 
 	end_headers();
 
-	argv[0] = svc->name;
-	run_service(argv);
+	run_service(svc->name, argv);
 	strbuf_release(&buf);
 }
 
-- 
1.7.5.1

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

[Junio C Hamano]

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.

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

[Johannes Schindelin]

Hi,

On Tue, 24 May 2011, Junio C Hamano wrote:

> 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 had to read the example call to understand that 'virtual repository' 
means 'one real catch-em-all repository'.

I wonder about two things, though:

1) Would teaching git clone to understand "-t this/repo/*" help?

2) You're extending the protocol by appending the prefix after the SHA-1, 
   and I stopped halfway through the patch trying to find information 
   which I now think should be in the commit message: a) why? b) why does 
   it not break when one of the two sides is a previous version?

Ciao,
Dscho

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

[Jamey Sharp]

[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]

On Wed, May 25, 2011 at 08:51:07AM +0200, Johannes Schindelin wrote:
> On Tue, 24 May 2011, Junio C Hamano wrote:
> > 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 had to read the example call to understand that 'virtual repository' 
> means 'one real catch-em-all repository'.
> 
> I wonder about two things, though:
> 
> 1) Would teaching git clone to understand "-t this/repo/*" help?

Sure, that would be an improvement for our use case, but we expect to
have lots of these virtual repositories, so I think we'd rather have the
server-side help we proposed in these patches. Seems to me that
wildcards in git-clone would be nice for other use cases, though.

> 2) You're extending the protocol by appending the prefix after the SHA-1, 
>    and I stopped halfway through the patch trying to find information 
>    which I now think should be in the commit message: a) why? b) why does 
>    it not break when one of the two sides is a previous version?

I don't think we're changing the protocol in any way...? In all of our
tests, the client was Debian's package of git version 1.7.5.1. And note
that none of these patches touch client-side protocol code; it's all in
the server-side upload-pack and receive-pack.

If we have changed the protocol, it was unintentional and we should fix
it.

Jamey

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Junio C Hamano]

Jamey Sharp <jamey@minilop.net> writes:

>> I had to read the example call to understand that 'virtual repository' 
>> means 'one real catch-em-all repository'.
>> 
>> I wonder about two things, though:
>> 
>> 1) Would teaching git clone to understand "-t this/repo/*" help?
>
> Sure, that would be an improvement for our use case,...

Hmm, what does the "-t" option do?  Is there a side-band communication
between you guys that I am not seeing?  I didn't see anything to make me
say "Sure" or otherwise.

I had a feeling that you wanted to keep the illusion to the users that you
are serving multiple repositories independently, so a solution that does
not have to make "git clone" on the other side aware of the layout on your
server would probably be more preferrable to you anyway.

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

[Johannes Schindelin]

Dear Junio,

On Wed, 25 May 2011, Junio C Hamano wrote:

> Jamey Sharp <jamey@minilop.net> writes:
> 
> >> I had to read the example call to understand that 'virtual 
> >> repository' means 'one real catch-em-all repository'.
> >> 
> >> I wonder about two things, though:
> >> 
> >> 1) Would teaching git clone to understand "-t this/repo/*" help?
> >
> > Sure, that would be an improvement for our use case,...
> 
> Hmm, what does the "-t" option do?

Well, I assumed that "git clone" would have adopted "git remote add"s -t 
option in the meantime.

Hth,
Johannes

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

[Johannes Schindelin]

Hi,

On Wed, 25 May 2011, Jamey Sharp wrote:

> On Wed, May 25, 2011 at 08:51:07AM +0200, Johannes Schindelin wrote:
>
> > 2) You're extending the protocol by appending the prefix after the 
> >    SHA-1, and I stopped halfway through the patch trying to find 
> >    information which I now think should be in the commit message: a)  
> >    why? b) why does it not break when one of the two sides is a 
> >    previous version?
> 
> I don't think we're changing the protocol in any way...?

Did your patch series not contain a change that sends a capability with 
the prefix appended?

Ciao,
Johannes

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

[Josh Triplett]

On Thu, May 26, 2011 at 01:53:42AM +0200, Johannes Schindelin wrote:
> On Wed, 25 May 2011, Jamey Sharp wrote:
> > On Wed, May 25, 2011 at 08:51:07AM +0200, Johannes Schindelin wrote:
> > > 2) You're extending the protocol by appending the prefix after the 
> > >    SHA-1, and I stopped halfway through the patch trying to find 
> > >    information which I now think should be in the commit message: a)  
> > >    why? b) why does it not break when one of the two sides is a 
> > >    previous version?
> > 
> > I don't think we're changing the protocol in any way...?
> 
> Did your patch series not contain a change that sends a capability with 
> the prefix appended?

Not that we know of.  Are we missing something?

- Josh Triplett

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

[Johannes Schindelin]

Hi,

On Wed, 25 May 2011, Josh Triplett wrote:

> On Thu, May 26, 2011 at 01:53:42AM +0200, Johannes Schindelin wrote:
> > On Wed, 25 May 2011, Jamey Sharp wrote:
> > > On Wed, May 25, 2011 at 08:51:07AM +0200, Johannes Schindelin wrote:
> > > > 2) You're extending the protocol by appending the prefix after the 
> > > >    SHA-1, and I stopped halfway through the patch trying to find 
> > > >    information which I now think should be in the commit message: a)  
> > > >    why? b) why does it not break when one of the two sides is a 
> > > >    previous version?
> > > 
> > > I don't think we're changing the protocol in any way...?
> > 
> > Did your patch series not contain a change that sends a capability with 
> > the prefix appended?
> 
> Not that we know of.  Are we missing something?

This is a change of protocol by my understanding:

-- snip --
 	if (sent_capabilities)
-		packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
+		packet_write(1, "%s %s%s\n", sha1_to_hex(sha1), refnameprefix, path);
-- snap --

Of course, you're free to ignore my comments just like everybody else on 
the Git mailing list.

Ciao,
Johannes

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> Not that we know of.  Are we missing something?
>
> This is a change of protocol by my understanding:
>
> -- snip --
>  	if (sent_capabilities)
> -		packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
> +		packet_write(1, "%s %s%s\n", sha1_to_hex(sha1), refnameprefix, path);
> -- snap --

I think this is not a change in the protocol per-se, but rather a botched
attempt to make refs/virt/one/refsheads/foo this side has appear as if it
is refs/heads/foo to the other side. In other words, you probably spotted
a bug.

When read with the "chroot" analogy of Peff and Shawn earlier in the
thread in mind, shouldn't the sending end that is pretending that only a
part of its ref namespace is actually the whole thing _stripping_ the
prefix from the real namespace, rather than appending the extra prefix?

I've been down sick, feeling feverish, this afternoon, so I may be
remembering what I understood while reading the code incorrectly, but that
was the impression I got.