[PATCHv4 1/4] Refactor for_each_ref variants to use for_each_ref_in and avoid magic numbers

[PATCHv4 1/4] Refactor for_each_ref variants to use for_each_ref_in and avoid magic numbers

[Jamey Sharp]

From: Josh Triplett <josh@joshtriplett.org>

Several variants of the for_each_ref functions call do_for_each_ref with
both a fixed string prefix and the hardcoded length of that prefix.
Furthermore, for_each_ref and for_each_ref_submodule passed "refs/" but
a length of 0, which caused do_for_each_ref to ignore the "refs/".

Change do_for_each_ref to use prefixcmp instead, and change the
for_each_ref variants to call for_each_ref_in with the prefix they
actually want.

Leave the separate "trim" parameter for callers that want to require a
prefix but not strip off that prefix.

Commit by Josh Triplett and Jamey Sharp.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
---
With this change the "trim" parameter always equals strlen(base), but we
use trim=0 again in a later patch in this series.

 refs.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/refs.c b/refs.c
index e3c0511..60cebe6 100644
--- a/refs.c
+++ b/refs.c
@@ -584,7 +584,7 @@ int read_ref(const char *ref, unsigned char *sha1)
 static int do_one_ref(const char *base, each_ref_fn fn, int trim,
 		      int flags, void *cb_data, struct ref_list *entry)
 {
-	if (strncmp(base, entry->name, trim))
+	if (prefixcmp(entry->name, base))
 		return 0;
 
 	if (!(flags & DO_FOR_EACH_INCLUDE_BROKEN)) {
@@ -728,12 +728,12 @@ int head_ref_submodule(const char *submodule, each_ref_fn fn, void *cb_data)
 
 int for_each_ref(each_ref_fn fn, void *cb_data)
 {
-	return do_for_each_ref(NULL, "refs/", fn, 0, 0, cb_data);
+	return for_each_ref_in("", fn, cb_data);
 }
 
 int for_each_ref_submodule(const char *submodule, each_ref_fn fn, void *cb_data)
 {
-	return do_for_each_ref(submodule, "refs/", fn, 0, 0, cb_data);
+	return for_each_ref_in_submodule(submodule, "", fn, cb_data);
 }
 
 int for_each_ref_in(const char *prefix, each_ref_fn fn, void *cb_data)
@@ -779,7 +779,7 @@ int for_each_remote_ref_submodule(const char *submodule, each_ref_fn fn, void *c
 
 int for_each_replace_ref(each_ref_fn fn, void *cb_data)
 {
-	return do_for_each_ref(NULL, "refs/replace/", fn, 13, 0, cb_data);
+	return for_each_ref_in("refs/replace/", fn, cb_data);
 }
 
 int for_each_glob_ref_in(each_ref_fn fn, const char *pattern,
@@ -819,7 +819,7 @@ int for_each_glob_ref(each_ref_fn fn, const char *pattern, void *cb_data)
 
 int for_each_rawref(each_ref_fn fn, void *cb_data)
 {
-	return do_for_each_ref(NULL, "refs/", fn, 0,
+	return do_for_each_ref(NULL, "", fn, 0,
 			       DO_FOR_EACH_INCLUDE_BROKEN, cb_data);
 }
 
-- 
1.7.5.3

[PATCHv4 2/4] Add infrastructure for ref namespaces

[Jamey Sharp]

From: Josh Triplett <josh@joshtriplett.org>

Add support for dividing the refs of a single repository into multiple
namespaces, each of which can have its own branches, tags, and HEAD.
Git can expose each namespace as an independent repository to pull from
and push to, while sharing the object store, and exposing all the refs
to operations such as git-gc.

Storing multiple repositories as namespaces of a single repository
avoids storing duplicate copies of the same objects, such as when
storing multiple branches of the same source.  The alternates mechanism
provides similar support for avoiding duplicates, but alternates do not
prevent duplication between new objects added to the repositories
without ongoing maintenance, while namespaces do.

To specify a namespace, set the GIT_NAMESPACE environment variable to
the namespace.  For each ref namespace, git stores the corresponding
refs in a directory under refs/namespaces/.  For example,
GIT_NAMESPACE=foo will store refs under refs/namespaces/foo/.  You can
also specify namespaces via the --namespace option to git.

Note that namespaces which include a / will expand to a hierarchy of
namespaces; for example, GIT_NAMESPACE=foo/bar will store refs under
refs/namespaces/foo/refs/namespaces/bar/.  This makes GIT_NAMESPACE
behave hierarchically, and avoids ambiguity with namespaces such as
foo/refs/heads.

This adds the infrastructure for ref namespaces: handling the
GIT_NAMESPACE environment variable and --namespace option, and iterating
over refs in a namespace.  Subsequent commits use this infrastructure to
implement the user-visible support for ref namespaces.

Commit by Josh Triplett and Jamey Sharp.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
---
In v4, we took Jeff King's suggestion to do most of the work in refs.c,
enforcing a naming convention that places HEAD with the namespaced refs.
We also renamed the concept from "virtual repositories" to "namespaces",
in hopes that that term will be more clear.

 cache.h                                |    3 ++
 contrib/completion/git-completion.bash |    1 +
 environment.c                          |   41 ++++++++++++++++++++++++++++++++
 git.c                                  |   18 ++++++++++++-
 refs.c                                 |   25 +++++++++++++++++++
 refs.h                                 |    3 ++
 6 files changed, 89 insertions(+), 2 deletions(-)

diff --git a/cache.h b/cache.h
index e11cf6a..b256a94 100644
--- a/cache.h
+++ b/cache.h
@@ -379,6 +379,7 @@ static inline enum object_type object_type(unsigned int mode)
 }
 
 #define GIT_DIR_ENVIRONMENT "GIT_DIR"
+#define GIT_NAMESPACE_ENVIRONMENT "GIT_NAMESPACE"
 #define GIT_WORK_TREE_ENVIRONMENT "GIT_WORK_TREE"
 #define DEFAULT_GIT_DIR_ENVIRONMENT ".git"
 #define DB_ENVIRONMENT "GIT_OBJECT_DIRECTORY"
@@ -419,6 +420,8 @@ extern char *get_object_directory(void);
 extern char *get_index_file(void);
 extern char *get_graft_file(void);
 extern int set_git_dir(const char *path);
+extern const char *get_git_namespace(void);
+extern const char *strip_namespace(const char *namespaced_ref);
 extern const char *get_git_work_tree(void);
 extern const char *read_gitfile_gently(const char *path);
 extern void set_git_work_tree(const char *tree);
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index b36290f..b10a1ec 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2640,6 +2640,7 @@ _git ()
 			--exec-path
 			--html-path
 			--work-tree=
+			--namespace=
 			--help
 			"
 			;;
diff --git a/environment.c b/environment.c
index 94d58fd..aad274b 100644
--- a/environment.c
+++ b/environment.c
@@ -8,6 +8,7 @@
  * are.
  */
 #include "cache.h"
+#include "refs.h"
 
 char git_default_email[MAX_GITNAME];
 char git_default_name[MAX_GITNAME];
@@ -65,6 +66,9 @@ int core_preload_index = 0;
 char *git_work_tree_cfg;
 static char *work_tree;
 
+static const char *namespace;
+static size_t namespace_len;
+
 static const char *git_dir;
 static char *git_object_dir, *git_index_file, *git_graft_file;
 
@@ -86,6 +90,27 @@ const char * const local_repo_env[LOCAL_REPO_ENV_SIZE + 1] = {
 	NULL
 };
 
+static char *expand_namespace(const char *raw_namespace)
+{
+	struct strbuf buf = STRBUF_INIT;
+	struct strbuf **components, **c;
+
+	if (!raw_namespace || !*raw_namespace)
+		return xstrdup("");
+
+	strbuf_addstr(&buf, raw_namespace);
+	components = strbuf_split(&buf, '/');
+	strbuf_reset(&buf);
+	for (c = components; *c; c++)
+		if (strcmp((*c)->buf, "/") != 0)
+			strbuf_addf(&buf, "refs/namespaces/%s", (*c)->buf);
+	strbuf_list_free(components);
+	if (check_ref_format(buf.buf) != CHECK_REF_FORMAT_OK)
+		die("bad git namespace path \"%s\"", raw_namespace);
+	strbuf_addch(&buf, '/');
+	return strbuf_detach(&buf, NULL);
+}
+
 static void setup_git_env(void)
 {
 	git_dir = getenv(GIT_DIR_ENVIRONMENT);
@@ -111,6 +136,8 @@ static void setup_git_env(void)
 		git_graft_file = git_pathdup("info/grafts");
 	if (getenv(NO_REPLACE_OBJECTS_ENVIRONMENT))
 		read_replace_refs = 0;
+	namespace = expand_namespace(getenv(GIT_NAMESPACE_ENVIRONMENT));
+	namespace_len = strlen(namespace);
 }
 
 int is_bare_repository(void)
@@ -131,6 +158,20 @@ const char *get_git_dir(void)
 	return git_dir;
 }
 
+const char *get_git_namespace(void)
+{
+	if (!namespace)
+		setup_git_env();
+	return namespace;
+}
+
+const char *strip_namespace(const char *namespaced_ref)
+{
+	if (prefixcmp(namespaced_ref, get_git_namespace()) != 0)
+		return NULL;
+	return namespaced_ref + namespace_len;
+}
+
 static int git_work_tree_initialized;
 
 /*
diff --git a/git.c b/git.c
index 89721d4..98cbf7b 100644
--- a/git.c
+++ b/git.c
@@ -7,8 +7,8 @@
 
 const char git_usage_string[] =
 	"git [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]\n"
-	"           [-p|--paginate|--no-pager] [--no-replace-objects]\n"
-	"           [--bare] [--git-dir=<path>] [--work-tree=<path>]\n"
+	"           [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]\n"
+	"           [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]\n"
 	"           [-c name=value] [--help]\n"
 	"           <command> [<args>]";
 
@@ -126,6 +126,20 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
 			setenv(GIT_DIR_ENVIRONMENT, cmd + 10, 1);
 			if (envchanged)
 				*envchanged = 1;
+		} else if (!strcmp(cmd, "--namespace")) {
+			if (*argc < 2) {
+				fprintf(stderr, "No directory given for --namespace.\n" );
+				usage(git_usage_string);
+			}
+			setenv(GIT_NAMESPACE_ENVIRONMENT, (*argv)[1], 1);
+			if (envchanged)
+				*envchanged = 1;
+			(*argv)++;
+			(*argc)--;
+		} else if (!prefixcmp(cmd, "--namespace=")) {
+			setenv(GIT_NAMESPACE_ENVIRONMENT, cmd + 12, 1);
+			if (envchanged)
+				*envchanged = 1;
 		} else if (!strcmp(cmd, "--work-tree")) {
 			if (*argc < 2) {
 				fprintf(stderr, "No directory given for --work-tree.\n" );
diff --git a/refs.c b/refs.c
index 60cebe6..96f64ed 100644
--- a/refs.c
+++ b/refs.c
@@ -782,6 +782,31 @@ int for_each_replace_ref(each_ref_fn fn, void *cb_data)
 	return for_each_ref_in("refs/replace/", fn, cb_data);
 }
 
+int head_ref_namespaced(each_ref_fn fn, void *cb_data)
+{
+	struct strbuf buf = STRBUF_INIT;
+	int ret = 0;
+	unsigned char sha1[20];
+	int flag;
+
+	strbuf_addf(&buf, "%sHEAD", get_git_namespace());
+	if (resolve_ref(buf.buf, sha1, 1, &flag))
+		ret = fn(buf.buf, sha1, flag, cb_data);
+	strbuf_release(&buf);
+
+	return ret;
+}
+
+int for_each_namespaced_ref(each_ref_fn fn, void *cb_data)
+{
+	struct strbuf buf = STRBUF_INIT;
+	int ret;
+	strbuf_addf(&buf, "%srefs/", get_git_namespace());
+	ret = do_for_each_ref(NULL, buf.buf, fn, 0, 0, cb_data);
+	strbuf_release(&buf);
+	return ret;
+}
+
 int for_each_glob_ref_in(each_ref_fn fn, const char *pattern,
 	const char *prefix, void *cb_data)
 {
diff --git a/refs.h b/refs.h
index 5e7a9a5..9a5c9e0 100644
--- a/refs.h
+++ b/refs.h
@@ -36,6 +36,9 @@ extern int for_each_tag_ref_submodule(const char *submodule, each_ref_fn fn, voi
 extern int for_each_branch_ref_submodule(const char *submodule, each_ref_fn fn, void *cb_data);
 extern int for_each_remote_ref_submodule(const char *submodule, each_ref_fn fn, void *cb_data);
 
+extern int head_ref_namespaced(each_ref_fn fn, void *cb_data);
+extern int for_each_namespaced_ref(each_ref_fn fn, void *cb_data);
+
 static inline const char *has_glob_specials(const char *pattern)
 {
 	return strpbrk(pattern, "?*[");
-- 
1.7.5.3

Re: [PATCHv4 2/4] Add infrastructure for ref namespaces

[Junio C Hamano]

Jamey Sharp <jamey@minilop.net> writes:

> Note that namespaces which include a / will expand to a hierarchy of
> namespaces; for example, GIT_NAMESPACE=foo/bar will store refs under
> refs/namespaces/foo/refs/namespaces/bar/.  This makes GIT_NAMESPACE
> behave hierarchically, and avoids ambiguity with namespaces such as
> foo/refs/heads.

Sorry, but I fail to see what problem you are trying to solve here.  I am
not suggesting that it would be better to do things in a way different
from what your patch does, but what problem will you have if you stored
the branch head for baz in refs/namespaces/foo/bar/refs/heads/baz given
the namespace foo/bar, and how does it solve that problem to store it
instead at refs/namespaces/foo/refs/namespaces/bar/refs/heads/baz?


> +int for_each_namespaced_ref(each_ref_fn fn, void *cb_data)

Just a naming and interface preference, but I would have called this
for-each-ref-in-namespace, perhaps giving the namespace as a parameter.

Re: [PATCHv4 2/4] Add infrastructure for ref namespaces

[Josh Triplett]

On Thu, Jun 02, 2011 at 03:44:33PM -0700, Junio C Hamano wrote:
> Jamey Sharp <jamey@minilop.net> writes:
> 
> > Note that namespaces which include a / will expand to a hierarchy of
> > namespaces; for example, GIT_NAMESPACE=foo/bar will store refs under
> > refs/namespaces/foo/refs/namespaces/bar/.  This makes GIT_NAMESPACE
> > behave hierarchically, and avoids ambiguity with namespaces such as
> > foo/refs/heads.
> 
> Sorry, but I fail to see what problem you are trying to solve here.  I am
> not suggesting that it would be better to do things in a way different
> from what your patch does, but what problem will you have if you stored
> the branch head for baz in refs/namespaces/foo/bar/refs/heads/baz given
> the namespace foo/bar, and how does it solve that problem to store it
> instead at refs/namespaces/foo/refs/namespaces/bar/refs/heads/baz?

Two reasons.  First, if you use GIT_NAMESPACE=foo (which puts its refs
under refs/namespaces/foo/refs/{heads,tags}), and also used
GIT_NAMESPACE=foo/refs/heads, that would put its refs under
refs/namespaces/foo/refs/heads/refs/{heads,tags}, which would make them
potentially conflict with foo's references.  So, for instance, you could
end up with directory/file conflicts in the refs directory.  Using
hierarchies avoids any possible conflicts and corner cases there.

Second, by making the namespaces hierarchical, we provide a kind of
composability, similar to that suggested by the analogy to chroots.
With the way we've constructed them, cloning a repo with
GIT_NAMESPACE=foo/bar has the same effect as cloning a repo with
GIT_NAMESPACE=foo and cloning from that repo with GIT_NAMESPACE=bar.

> > +int for_each_namespaced_ref(each_ref_fn fn, void *cb_data)
> 
> Just a naming and interface preference, but I would have called this
> for-each-ref-in-namespace, perhaps giving the namespace as a parameter.

for_each_ref_in and other variants already exist for that purpose;
for_each_namespaced_ref exists to automatically uses GIT_NAMESPACE.
Happy to rename it if you have another preference, but I don't think it
makes sense to support passing in arbitrary namespaces when the callers
only use it to access the currently requested namespace.  If some
situation arises in later code that needs to handle arbitrary
namespaces, it seems easy enough to provide a more generalized function
at that point, but doing so now would just make the existing callers
more complex by forcing them to do the call to get_git_namespace()
rather than allowing for_each_namespaced_ref to do it.

As far as naming, though, we have no preference whatsoever about the
color of the bikeshed. :)

- Josh Triplett

Re: [PATCHv4 2/4] Add infrastructure for ref namespaces

[Junio C Hamano]

Josh Triplett <josh@joshtriplett.org> writes:

> ... I don't think it
> makes sense to support passing in arbitrary namespaces when the callers
> only use it to access the currently requested namespace.  If some
> situation arises in later code that needs to handle arbitrary
> namespaces, it seems easy enough to provide a more generalized function
> at that point, but doing so now would just make the existing callers
> more complex by forcing them to do the call to get_git_namespace()
> rather than allowing for_each_namespaced_ref to do it.

If you do not pass the namespace around from day one, wouldn't it make it
more cumbersome to later extend the API so that you can have more than one
namespace active at the same time? For example, even with today's code,
when responding to a push, the receiving repository issues a ls-remote
request to its alternate repository to learn the tips of its refs, and at
that point, the side of you who is responding to a push is using the
namespace from the push client, while you acting as a fetch/ls-remote
client would be in a different namespace. The different namespace happens
to be "no funny namespace business" plain vanilla one, but I think you get
the point. I do not mind seeing the very top-level caller of ref iterator
calling get-namespace, but I would find it a bad taste if a function very
deep in a callchain has to call get-namespace (meaning, you can only have
one namespace active at a time) only because the caller does not pass it
in.

But perhaps I am looking too far into the future and worried too much.

Re: [PATCHv4 2/4] Add infrastructure for ref namespaces

[Josh Triplett]

On Thu, Jun 02, 2011 at 07:51:22PM -0700, Junio C Hamano wrote:
> Josh Triplett <josh@joshtriplett.org> writes:
> 
> > ... I don't think it
> > makes sense to support passing in arbitrary namespaces when the callers
> > only use it to access the currently requested namespace.  If some
> > situation arises in later code that needs to handle arbitrary
> > namespaces, it seems easy enough to provide a more generalized function
> > at that point, but doing so now would just make the existing callers
> > more complex by forcing them to do the call to get_git_namespace()
> > rather than allowing for_each_namespaced_ref to do it.
> 
> If you do not pass the namespace around from day one, wouldn't it make it
> more cumbersome to later extend the API so that you can have more than one
> namespace active at the same time? For example, even with today's code,
> when responding to a push, the receiving repository issues a ls-remote
> request to its alternate repository to learn the tips of its refs, and at
> that point, the side of you who is responding to a push is using the
> namespace from the push client, while you acting as a fetch/ls-remote
> client would be in a different namespace. The different namespace happens
> to be "no funny namespace business" plain vanilla one, but I think you get
> the point. I do not mind seeing the very top-level caller of ref iterator
> calling get-namespace, but I would find it a bad taste if a function very
> deep in a callchain has to call get-namespace (meaning, you can only have
> one namespace active at a time) only because the caller does not pass it
> in.
> 
> But perhaps I am looking too far into the future and worried too much.

I do understand your concern, and in the future some tools might need to
support multiple namespaces, but for now all the users only need to use
GIT_NAMESPACE, and I'd prefer to tailor the API for the convenience of
the callers that exist now on the assumption that the API seems trivial
to change later if it turns out we need it.  I don't think it makes
sense to try to design that future API without specific callers in mind.

- Josh Triplett

Re: [PATCHv4 2/4] Add infrastructure for ref namespaces

[Jakub Narebski]

Jamey Sharp <jamey@minilop.net> writes:

> From: Josh Triplett <josh@joshtriplett.org>
> 
> Add support for dividing the refs of a single repository into multiple
> namespaces, each of which can have its own branches, tags, and HEAD.
> Git can expose each namespace as an independent repository to pull from
> and push to, while sharing the object store, and exposing all the refs
> to operations such as git-gc.
[...]

By the way, after this feature is merged in, would you like for gitweb
to understand ref namespaces and offer browsing of separate namespaces
(sub-repositories)?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [PATCHv4 2/4] Add infrastructure for ref namespaces

[Josh Triplett]

On Fri, Jun 03, 2011 at 01:35:34AM -0700, Jakub Narebski wrote:
> Jamey Sharp <jamey@minilop.net> writes:
> 
> > From: Josh Triplett <josh@joshtriplett.org>
> > 
> > Add support for dividing the refs of a single repository into multiple
> > namespaces, each of which can have its own branches, tags, and HEAD.
> > Git can expose each namespace as an independent repository to pull from
> > and push to, while sharing the object store, and exposing all the refs
> > to operations such as git-gc.
> [...]
> 
> By the way, after this feature is merged in, would you like for gitweb
> to understand ref namespaces and offer browsing of separate namespaces
> (sub-repositories)?

Yes, definitely!  We'd love to see gitweb handling namespaces
transparently, and presenting them identically to top-level
repositories.  (Also, gitweb would need to present the appropriate
repository URIs for cloning.)

Thanks,
Josh Triplett and Jamey Sharp

Re: [PATCHv4 2/4] Add infrastructure for ref namespaces

[Jakub Narebski]

On Fri, 3 June 2011, Josh Triplett wrote:
> On Fri, Jun 03, 2011 at 01:35:34AM -0700, Jakub Narebski wrote:
> > Jamey Sharp <jamey@minilop.net> writes:
> > 
> > > From: Josh Triplett <josh@joshtriplett.org>
> > > 
> > > Add support for dividing the refs of a single repository into multiple
> > > namespaces, each of which can have its own branches, tags, and HEAD.
> > > Git can expose each namespace as an independent repository to pull from
> > > and push to, while sharing the object store, and exposing all the refs
> > > to operations such as git-gc.
> > [...]
> > 
> > By the way, after this feature is merged in, would you like for gitweb
> > to understand ref namespaces and offer browsing of separate namespaces
> > (sub-repositories)?
> 
> Yes, definitely!  We'd love to see gitweb handling namespaces
> transparently, and presenting them identically to top-level
> repositories.  (Also, gitweb would need to present the appropriate
> repository URIs for cloning.)

Note that for gitweb support we would need some easy way to list all
namespaces that given repository provides.  But that is for the future.

BTW. what do you think about treating repository with own refs and with
namespaces similarly to how "forks" are handled in gitweb now?
-- 
Jakub Narebski
Poland

Re: [PATCHv4 2/4] Add infrastructure for ref namespaces

[Josh Triplett]

On Wed, Jun 08, 2011 at 11:41:25AM +0200, Jakub Narebski wrote:
> On Fri, 3 June 2011, Josh Triplett wrote:
> > On Fri, Jun 03, 2011 at 01:35:34AM -0700, Jakub Narebski wrote:
> > > Jamey Sharp <jamey@minilop.net> writes:
> > > 
> > > > From: Josh Triplett <josh@joshtriplett.org>
> > > > 
> > > > Add support for dividing the refs of a single repository into multiple
> > > > namespaces, each of which can have its own branches, tags, and HEAD.
> > > > Git can expose each namespace as an independent repository to pull from
> > > > and push to, while sharing the object store, and exposing all the refs
> > > > to operations such as git-gc.
> > > [...]
> > > 
> > > By the way, after this feature is merged in, would you like for gitweb
> > > to understand ref namespaces and offer browsing of separate namespaces
> > > (sub-repositories)?
> > 
> > Yes, definitely!  We'd love to see gitweb handling namespaces
> > transparently, and presenting them identically to top-level
> > repositories.  (Also, gitweb would need to present the appropriate
> > repository URIs for cloning.)
> 
> Note that for gitweb support we would need some easy way to list all
> namespaces that given repository provides.  But that is for the future.
> 
> BTW. what do you think about treating repository with own refs and with
> namespaces similarly to how "forks" are handled in gitweb now?

Different namespaces won't necessarily represent forks of the same
repository; they may represent entirely separate repositories, with the
use of namespaces merely a server-side implementation detail to save
space.  I'd suggest presenting them as separate repositories.

- Josh Triplett

Re: [PATCHv4 2/4] Add infrastructure for ref namespaces

[Jakub Narebski]

On Thu, 9 Jun 2011, Josh Triplett wrote:
> On Wed, Jun 08, 2011 at 11:41:25AM +0200, Jakub Narebski wrote:

> > BTW. what do you think about treating repository with own refs and with
                                                     ^^^^^^^^^^^^^
> > namespaces similarly to how "forks" are handled in gitweb now?
> 
> Different namespaces won't necessarily represent forks of the same
> repository; they may represent entirely separate repositories, with the
> use of namespaces merely a server-side implementation detail to save
> space.  I'd suggest presenting them as separate repositories.

What I wanted to say that if repository with namespaces has its own
not namespaced refs, then (sub)namespaces are probably forks, and
"forks"-like behavior would be a good idea.

If namespaced repository serves only to save space, then it wouldn't
have its own refs, only namespaced ones.  Then we would list them
as separate repositories.

-- 
Jakub Narebski
Poland

[PATCHv4 3/4] Support ref namespaces for remote repositories via upload-pack and receive-pack

[Jamey Sharp]

From: Josh Triplett <josh@joshtriplett.org>

Change upload-pack and receive-pack to use the namespace-prefixed refs
when working with the repository, and use the unprefixed refs when
talking to the client, maintaining the masquerade.  This allows
clone, pull, fetch, and push to work with a suitably configured
GIT_NAMESPACE.

With appropriate configuration, this also allows http-backend to expose
namespaces as multiple repositories with different paths.  This only
requires setting GIT_NAMESPACE, which http-backend passes through to
upload-pack and receive-pack.

Commit by Josh Triplett and Jamey Sharp.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
---
This patch is not that different from v3, but now uses general
infrastructure from refs.c introduced in patch 2/4.

 builtin/receive-pack.c |   32 +++++++++++++++++++++++++-------
 upload-pack.c          |   15 ++++++++-------
 2 files changed, 33 insertions(+), 14 deletions(-)

diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index e1a687a..9bb268a 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -109,6 +109,7 @@ 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)
 {
+	path = path ? strip_namespace(path) : "capabilities^{}";
 	if (sent_capabilities)
 		packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
 	else
@@ -122,9 +123,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_namespaced_ref(show_ref, NULL);
 	if (!sent_capabilities)
-		show_ref("capabilities^{}", null_sha1, 0, NULL);
+		show_ref(NULL, null_sha1, 0, NULL);
 
 }
 
@@ -333,6 +334,8 @@ static void refuse_unconfigured_deny_delete_current(void)
 static const char *update(struct command *cmd)
 {
 	const char *name = cmd->ref_name;
+	struct strbuf namespaced_name_buf = STRBUF_INIT;
+	const char *namespaced_name;
 	unsigned char *old_sha1 = cmd->old_sha1;
 	unsigned char *new_sha1 = cmd->new_sha1;
 	struct ref_lock *lock;
@@ -343,7 +346,10 @@ static const char *update(struct command *cmd)
 		return "funny refname";
 	}
 
-	if (is_ref_checked_out(name)) {
+	strbuf_addf(&namespaced_name_buf, "%s%s", get_git_namespace(), name);
+	namespaced_name = strbuf_detach(&namespaced_name_buf, NULL);
+
+	if (is_ref_checked_out(namespaced_name)) {
 		switch (deny_current_branch) {
 		case DENY_IGNORE:
 			break;
@@ -371,7 +377,7 @@ static const char *update(struct command *cmd)
 			return "deletion prohibited";
 		}
 
-		if (!strcmp(name, head_name)) {
+		if (!strcmp(namespaced_name, head_name)) {
 			switch (deny_delete_current) {
 			case DENY_IGNORE:
 				break;
@@ -427,14 +433,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(namespaced_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(namespaced_name, old_sha1, 0);
 		if (!lock) {
 			rp_error("failed to lock %s", name);
 			return "failed to lock";
@@ -491,17 +497,29 @@ static void run_update_post_hook(struct command *commands)
 
 static void check_aliased_update(struct command *cmd, struct string_list *list)
 {
+	struct strbuf buf = STRBUF_INIT;
+	const char *dst_name;
 	struct string_list_item *item;
 	struct command *dst_cmd;
 	unsigned char sha1[20];
 	char cmd_oldh[41], cmd_newh[41], dst_oldh[41], dst_newh[41];
 	int flag;
 
-	const char *dst_name = resolve_ref(cmd->ref_name, sha1, 0, &flag);
+	strbuf_addf(&buf, "%s%s", get_git_namespace(), cmd->ref_name);
+	dst_name = resolve_ref(buf.buf, sha1, 0, &flag);
+	strbuf_release(&buf);
 
 	if (!(flag & REF_ISSYMREF))
 		return;
 
+	dst_name = strip_namespace(dst_name);
+	if (!dst_name) {
+		rp_error("refusing update to broken symref '%s'", cmd->ref_name);
+		cmd->skip_update = 1;
+		cmd->error_string = "broken symref";
+		return;
+	}
+
 	if ((item = string_list_lookup(list, dst_name)) == NULL)
 		return;
 
diff --git a/upload-pack.c b/upload-pack.c
index ce5cbbe..267e5b1 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -641,16 +641,17 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
 		" side-band-64k ofs-delta shallow no-progress"
 		" include-tag multi_ack_detailed";
 	struct object *o = parse_object(sha1);
+	const char *refname_nons = strip_namespace(refname);
 
 	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%c%s%s\n", sha1_to_hex(sha1), refname_nons,
 			     0, capabilities,
 			     stateless_rpc ? " no-done" : "");
 	else
-		packet_write(1, "%s %s\n", sha1_to_hex(sha1), refname);
+		packet_write(1, "%s %s\n", sha1_to_hex(sha1), refname_nons);
 	capabilities = NULL;
 	if (!(o->flags & OUR_REF)) {
 		o->flags |= OUR_REF;
@@ -659,7 +660,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^{}\n", sha1_to_hex(o->sha1), refname_nons);
 	}
 	return 0;
 }
@@ -680,12 +681,12 @@ static void upload_pack(void)
 {
 	if (advertise_refs || !stateless_rpc) {
 		reset_timeout();
-		head_ref(send_ref, NULL);
-		for_each_ref(send_ref, NULL);
+		head_ref_namespaced(send_ref, NULL);
+		for_each_namespaced_ref(send_ref, NULL);
 		packet_flush(1);
 	} else {
-		head_ref(mark_our_ref, NULL);
-		for_each_ref(mark_our_ref, NULL);
+		head_ref_namespaced(mark_our_ref, NULL);
+		for_each_namespaced_ref(mark_our_ref, NULL);
 	}
 	if (advertise_refs)
 		return;
-- 
1.7.5.3

Re: [PATCHv4 3/4] Support ref namespaces for remote repositories via upload-pack and receive-pack

[Junio C Hamano]

Jamey Sharp <jamey@minilop.net> writes:

> diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> index e1a687a..9bb268a 100644
> --- a/builtin/receive-pack.c
> +++ b/builtin/receive-pack.c
> @@ -109,6 +109,7 @@ 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)
>  {
> +	path = path ? strip_namespace(path) : "capabilities^{}";
>  	if (sent_capabilities)
>  		packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
>  	else

This feels really ugly.

Logically the stripping of "path" should happen before the caller calls
this function, as the purpose of this function is "given a token and
object name, produce one line of 'I have this at here' protocol message,
which is defined to have the capability list tucked after the first of
such messages in an exchange". It now is "the token has to be a path in a
namespace; the only exception is when the token is NULL, in which case we
always send 'capabilities^{}'".

It also is a very selfish solution for an immediate issue(*) that does not
give much considertation for people who may want to add new things in the
future, as the _only_ possible special case is to send in NULL.

The immediate issue you wanted to solve, I think, is that it is not
convenient to strip in the caller as this is a callback. Still, I think it
should be easy to do something like...

	static int show_ref_message(const char *path,
        				 const unsigned char *sha1)
	{
		... original show_ref() implementation comes here ...
	}

        static int show_ref_cb(const char *path,
			        const unsigned char *sha1,
                                int flag, void *cb_data)
	{
		return show_ref_message(strip_namespace(path), sha1);
        }
        
and give the latter as the callback to for_each_ref_in_namespace().

And the call to run "capabilities^{}" when there is no ref can call
show_ref_message() directly.

Re: [PATCHv4 3/4] Support ref namespaces for remote repositories via upload-pack and receive-pack

[josh]

On Thu, Jun 02, 2011 at 04:05:23PM -0700, Junio C Hamano wrote:
> Jamey Sharp <jamey@minilop.net> writes:
> 
> > diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> > index e1a687a..9bb268a 100644
> > --- a/builtin/receive-pack.c
> > +++ b/builtin/receive-pack.c
> > @@ -109,6 +109,7 @@ 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)
> >  {
> > +	path = path ? strip_namespace(path) : "capabilities^{}";
> >  	if (sent_capabilities)
> >  		packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
> >  	else
> 
> This feels really ugly.
> 
> Logically the stripping of "path" should happen before the caller calls
> this function, as the purpose of this function is "given a token and
> object name, produce one line of 'I have this at here' protocol message,
> which is defined to have the capability list tucked after the first of
> such messages in an exchange". It now is "the token has to be a path in a
> namespace; the only exception is when the token is NULL, in which case we
> always send 'capabilities^{}'".
> 
> It also is a very selfish solution for an immediate issue(*) that does not
> give much considertation for people who may want to add new things in the
> future, as the _only_ possible special case is to send in NULL.
> 
> The immediate issue you wanted to solve, I think, is that it is not
> convenient to strip in the caller as this is a callback. Still, I think it
> should be easy to do something like...
> 
> 	static int show_ref_message(const char *path,
>         				 const unsigned char *sha1)
> 	{
> 		... original show_ref() implementation comes here ...
> 	}
> 
>         static int show_ref_cb(const char *path,
> 			        const unsigned char *sha1,
>                                 int flag, void *cb_data)
> 	{
> 		return show_ref_message(strip_namespace(path), sha1);
>         }
>         
> and give the latter as the callback to for_each_ref_in_namespace().
> 
> And the call to run "capabilities^{}" when there is no ref can call
> show_ref_message() directly.

Fair enough.  We'd thought of NULL as a fairly logical representation
for a null ref sent as a dummy ref just to send capabilities, but we can
easily rework the functions so that show_ref has the semantic you
suggest and expects an un-namespaced ref, since show_ref doesn't need
the original namespaced ref.  We'll do this in the next version of the
patch series.

- Josh Triplett

Re: [PATCHv4 3/4] Support ref namespaces for remote repositories via upload-pack and receive-pack

[Junio C Hamano]

josh@joshtriplett.org writes:

> Fair enough.  We'd thought of NULL as a fairly logical representation
> for a null ref sent as a dummy ref just to send capabilities,...

I am not objecting to that part. NULL may be a logical thing to throw at
when the interface is to take only strings that begin with refs/... and
you have to occasionally send something different.

But that is a line of thought that is only valid while there is only one
"something different" (i.e. "capabilities^{}") and the current code
happens to have only one such different thing to send, but the approach
closes the door to allow us sending things other than that single
exception in the future without redoing your patch. That was what I found
objectionable.

[PATCHv4 4/4] Add documentation for ref namespaces

[Jamey Sharp]

From: Josh Triplett <josh@joshtriplett.org>

Document the namespace mechanism in a new gitnamespaces(7) page.
Reference it from receive-pack and upload-pack.

Document the new --namespace option and GIT_NAMESPACE environment
variable in git(1), and reference gitnamespaces(7).

Add a sample Apache configuration to http-backend(1) to support
namespaced repositories, and reference gitnamespaces(7).

Commit by Josh Triplett and Jamey Sharp.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
---
In v4 we've tried to address reviewers' concerns about unclear and
inadequate documentation, and of course updated for functional changes
and revised terminology in this revision of the patch series.

Note that the "CONVENTIONS" section from v3's documentation is gone
because there is now only one way to set up namespaces.

 Documentation/Makefile                 |    2 +-
 Documentation/git-http-backend.txt     |    8 ++++
 Documentation/git-receive-pack.txt     |    2 +-
 Documentation/git-upload-pack.txt      |    4 ++
 Documentation/git.txt                  |   13 +++++-
 Documentation/gitnamespaces.txt        |   71 ++++++++++++++++++++++++++++++++
 contrib/completion/git-completion.bash |    2 +-
 7 files changed, 97 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/gitnamespaces.txt

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 36989b7..2004fbe 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -6,7 +6,7 @@ MAN5_TXT=gitattributes.txt gitignore.txt gitmodules.txt githooks.txt \
 	gitrepository-layout.txt
 MAN7_TXT=gitcli.txt gittutorial.txt gittutorial-2.txt \
 	gitcvs-migration.txt gitcore-tutorial.txt gitglossary.txt \
-	gitdiffcore.txt gitrevisions.txt gitworkflows.txt
+	gitdiffcore.txt gitnamespaces.txt gitrevisions.txt gitworkflows.txt
 
 MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT)
 MAN_XML=$(patsubst %.txt,%.xml,$(MAN_TXT))
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index 277d9e1..f4e0741 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 repositories from different linkgit:gitnamespaces[7] in a
+single repository:
++
+----------------------------------------------------------------
+SetEnvIf Request_URI "^/git/([^/]*)" GIT_NAMESPACE=$1
+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
diff --git a/Documentation/git-receive-pack.txt b/Documentation/git-receive-pack.txt
index f34e0ae..3534ba0 100644
--- a/Documentation/git-receive-pack.txt
+++ b/Documentation/git-receive-pack.txt
@@ -149,7 +149,7 @@ if the repository is packed and is served via a dumb transport.
 
 SEE ALSO
 --------
-linkgit:git-send-pack[1]
+linkgit:git-send-pack[1], linkgit:gitnamespaces[7]
 
 GIT
 ---
diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt
index 4c0ca9d..61a9a04 100644
--- a/Documentation/git-upload-pack.txt
+++ b/Documentation/git-upload-pack.txt
@@ -33,6 +33,10 @@ OPTIONS
 <directory>::
 	The repository to sync from.
 
+SEE ALSO
+--------
+linkgit:gitnamespaces[7]
+
 GIT
 ---
 Part of the linkgit:git[1] suite
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 65317cc..297590f 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -10,8 +10,8 @@ SYNOPSIS
 --------
 [verse]
 'git' [--version] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
-    [-p|--paginate|--no-pager] [--no-replace-objects]
-    [--bare] [--git-dir=<path>] [--work-tree=<path>]
+    [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
+    [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
     [-c <name>=<value>]
     [--help] <command> [<args>]
 
@@ -324,6 +324,11 @@ help ...`.
 	variable (see core.worktree in linkgit:git-config[1] for a
 	more detailed discussion).
 
+--namespace=<path>::
+	Set the git namespace.  See linkgit:gitnamespaces[7] for more
+	details.  Equivalent to setting the `GIT_NAMESPACE` environment
+	variable.
+
 --bare::
 	Treat the repository as a bare repository.  If GIT_DIR
 	environment is not set, it is set to the current working
@@ -588,6 +593,10 @@ git so take care if using Cogito etc.
 	This can also be controlled by the '--work-tree' command line
 	option and the core.worktree configuration variable.
 
+'GIT_NAMESPACE'::
+	Set the git namespace; see linkgit:gitnamespaces[7] for details.
+	The '--namespace' command-line option also sets this value.
+
 'GIT_CEILING_DIRECTORIES'::
 	This should be a colon-separated list of absolute paths.
 	If set, it is a list of directories that git should not chdir
diff --git a/Documentation/gitnamespaces.txt b/Documentation/gitnamespaces.txt
new file mode 100644
index 0000000..c11dd56
--- /dev/null
+++ b/Documentation/gitnamespaces.txt
@@ -0,0 +1,71 @@
+gitnamespaces(7)
+================
+
+NAME
+----
+gitnamespaces - Git namespaces
+
+DESCRIPTION
+-----------
+
+Git supports dividing the refs of a single repository into multiple
+namespaces, each of which has its own branches, tags, and HEAD.  Git can
+expose each namespace as an independent repository to pull from and push
+to, while sharing the object store, and exposing all the refs to
+operations such as linkgit:git-gc[1].
+
+Storing multiple repositories as namespaces of a single repository
+avoids storing duplicate copies of the same objects, such as when
+storing multiple branches of the same source.  The alternates mechanism
+provides similar support for avoiding duplicates, but alternates do not
+prevent duplication between new objects added to the repositories
+without ongoing maintenance, while namespaces do.
+
+To specify a namespace, set the `GIT_NAMESPACE` environment variable to
+the namespace.  For each ref namespace, git stores the corresponding
+refs in a directory under `refs/namespaces/`.  For example,
+`GIT_NAMESPACE=foo` will store refs under `refs/namespaces/foo/`.  You
+can also specify namespaces via the `--namespace` option to
+linkgit:git[1].
+
+Note that namespaces which include a `/` will expand to a hierarchy of
+namespaces; for example, `GIT_NAMESPACE=foo/bar` will store refs under
+`refs/namespaces/foo/refs/namespaces/bar/`.  This makes `GIT_NAMESPACE`
+behave hierarchically, and avoids ambiguity with namespaces such as
+`foo/refs/heads`.
+
+linkgit:git-upload-pack[1] and linkgit:git-receive-pack[1] rewrite the
+names of refs as specified by `GIT_NAMESPACE`.  git-upload-pack and
+git-receive-pack will ignore all references outside the specified
+namespace.
+
+The smart HTTP server, linkgit:git-http-backend[1], will pass
+GIT_NAMESPACE through to the backend programs; see
+linkgit:git-http-backend[1] for sample configuration to expose
+repository namespaces as repositories.
+
+For a simple local test, you can use linkgit:git-remote-ext[1]:
+
+----------
+git clone ext::'git --namespace=foo %s /tmp/prefixed.git'
+----------
+
+SECURITY
+--------
+
+Anyone with access to any namespace within a repository can potentially
+access objects from any other namespace stored in the same repository.
+You can't directly say "give me object ABCD" if you don't have a ref to
+it, but you can do some other sneaky things like:
+
+. Claiming to push ABCD, at which point the server will optimize out the
+  need for you to actually send it. Now you have a ref to ABCD and can
+  fetch it (claiming not to have it, of course).
+
+. Requesting other refs, claiming that you have ABCD, at which point the
+  server may generate deltas against ABCD.
+
+None of this causes a problem if you only host public repositories, or
+if everyone who may read one namespace may also read everything in every
+other namespace (for instance, if everyone in an organization has read
+permission to every repository).
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index b10a1ec..ec1c986 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1469,7 +1469,7 @@ _git_help ()
 	__gitcomp "$__git_all_commands $(__git_aliases)
 		attributes cli core-tutorial cvs-migration
 		diffcore gitk glossary hooks ignore modules
-		repository-layout tutorial tutorial-2
+		namespaces repository-layout tutorial tutorial-2
 		workflows
 		"
 }
-- 
1.7.5.3

Re: [PATCHv4 1/4] Refactor for_each_ref variants to use for_each_ref_in and avoid magic numbers

[Junio C Hamano]

Jamey Sharp <jamey@minilop.net> writes:

> Furthermore, for_each_ref and for_each_ref_submodule passed "refs/" but
> a length of 0, which caused do_for_each_ref to ignore the "refs/".

I had to read, stop, think for two days, until finally get to the point
that I _think_ I understand what you wanted to say.

As we use the same "trim" (meant to say "strip this many bytes from the
beginning of the full refname when calling the callback") to reject refs
outside the area we are interested in with the strncmp() at the beginning
of do_one_ref(), if do_for_each_ref() that is called by for_each_ref() fed
something outside "refs/" hierarchy to the function, the garbage ref that
is not a ref (as it is outside "refs/") will _not_ get filtered, which I
think is what you are trying to say by 'ignore the "refs/"'.

Which is technically a bug (we should be rejecting anything outside
"refs/", even when trim is set to 0) that dates as far back as e1e22e3
(Start handling references internally as a sorted in-memory list,
2006-09-11), but it didn't matter an iota because everything we read from
either loose or packed refs have "refs/" prefix.

Am I following your train of thought correctly so far?

> diff --git a/refs.c b/refs.c
> index e3c0511..60cebe6 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -584,7 +584,7 @@ int read_ref(const char *ref, unsigned char *sha1)
>  static int do_one_ref(const char *base, each_ref_fn fn, int trim,
>  		      int flags, void *cb_data, struct ref_list *entry)
>  {
> -	if (strncmp(base, entry->name, trim))
> +	if (prefixcmp(entry->name, base))
>  		return 0;
>  
>  	if (!(flags & DO_FOR_EACH_INCLUDE_BROKEN)) {
> ...
>  int for_each_ref(each_ref_fn fn, void *cb_data)
>  {
> -	return do_for_each_ref(NULL, "refs/", fn, 0, 0, cb_data);
> +	return for_each_ref_in("", fn, cb_data);
>  }

But then this looks like a bad way to fix that issue.  It will be a
non-issue as long as do-for-each-ref will never give anything outside
"refs/", but once that happens (say, a contaminated .git/packed-refs
file), this will show whatever that is outside "refs/", i.e. the issue the
proposed commit log message claims to address, which is "... which caused
do_for_each_ref to ignore", is not fixed here at all.

Shouldn't you be passing prefix and trim the same way as we have always
done, but just fixing the strncmp() at the beginning of do_one_ref()?

Re: [PATCHv4 1/4] Refactor for_each_ref variants to use for_each_ref_in and avoid magic numbers

[Josh Triplett]

On Thu, Jun 02, 2011 at 01:36:23PM -0700, Junio C Hamano wrote:
> Jamey Sharp <jamey@minilop.net> writes:
> > Furthermore, for_each_ref and for_each_ref_submodule passed "refs/" but
> > a length of 0, which caused do_for_each_ref to ignore the "refs/".
> 
> I had to read, stop, think for two days, until finally get to the point
> that I _think_ I understand what you wanted to say.
> 
> As we use the same "trim" (meant to say "strip this many bytes from the
> beginning of the full refname when calling the callback") to reject refs
> outside the area we are interested in with the strncmp() at the beginning
> of do_one_ref(), if do_for_each_ref() that is called by for_each_ref() fed
> something outside "refs/" hierarchy to the function, the garbage ref that
> is not a ref (as it is outside "refs/") will _not_ get filtered, which I
> think is what you are trying to say by 'ignore the "refs/"'.
> 
> Which is technically a bug (we should be rejecting anything outside
> "refs/", even when trim is set to 0) that dates as far back as e1e22e3
> (Start handling references internally as a sorted in-memory list,
> 2006-09-11), but it didn't matter an iota because everything we read from
> either loose or packed refs have "refs/" prefix.
> 
> Am I following your train of thought correctly so far?

Yes.  The calls that currently pass base="refs/" and trim=0 do not
filter the refs to those starting with "refs/" because they strncmp with
0 bytes.  We very intentionally ensured that this refactoring commit
made no semantic change to the current behavior.  As you point out,
everything produced from loose or packed refs will always start with
"refs/" anyway.

> > diff --git a/refs.c b/refs.c
> > index e3c0511..60cebe6 100644
> > --- a/refs.c
> > +++ b/refs.c
> > @@ -584,7 +584,7 @@ int read_ref(const char *ref, unsigned char *sha1)
> >  static int do_one_ref(const char *base, each_ref_fn fn, int trim,
> >  		      int flags, void *cb_data, struct ref_list *entry)
> >  {
> > -	if (strncmp(base, entry->name, trim))
> > +	if (prefixcmp(entry->name, base))
> >  		return 0;
> >  
> >  	if (!(flags & DO_FOR_EACH_INCLUDE_BROKEN)) {
> > ...
> >  int for_each_ref(each_ref_fn fn, void *cb_data)
> >  {
> > -	return do_for_each_ref(NULL, "refs/", fn, 0, 0, cb_data);
> > +	return for_each_ref_in("", fn, cb_data);
> >  }
> 
> But then this looks like a bad way to fix that issue.  It will be a
> non-issue as long as do-for-each-ref will never give anything outside
> "refs/", but once that happens (say, a contaminated .git/packed-refs
> file), this will show whatever that is outside "refs/", i.e. the issue the
> proposed commit log message claims to address, which is "... which caused
> do_for_each_ref to ignore", is not fixed here at all.

We didn't intend the commit message to suggest that we changed that
behavior; we intended that commit message to document why the commit
*didn't* change the behavior despite changing "refs/" to "".

> Shouldn't you be passing prefix and trim the same way as we have always
> done, but just fixing the strncmp() at the beginning of do_one_ref()?

I still think prefixcmp makes the most sense; if you pass a given base,
you expect do_for_each_ref to use that entire base as the prefix.  If
you want for_each_ref to start filtering out anything that doesn't start
with "refs/", then it could continue passing "refs/" and 0 rather than
calling for_each_ref_in.  It doesn't matter for this patch series either
way; we just didn't want this refactor to change the existing behavior.

- Josh Triplett

Re: [PATCHv4 1/4] Refactor for_each_ref variants to use for_each_ref_in and avoid magic numbers

[Junio C Hamano]

Josh Triplett <josh@joshtriplett.org> writes:

>> Shouldn't you be passing prefix and trim the same way as we have always
>> done, but just fixing the strncmp() at the beginning of do_one_ref()?
>
> I still think prefixcmp makes the most sense; if you pass a given base,

Using prefixcmp() instead of strncmp() there is what I meant by "fixing
the strncmp() at the beginning of do_one_ref()", so we are in agreement on
that point. What I found questionable was the removal of the trim
value. IOW, I would have expected the patch to be something like:

	if (prefixcmp(base, entry->name))
        	return 0; /* outside of our area -- ignore */
	... some other logic ...
        /* feed the callback, stripping the prefix */
        return fn(entry->name + trim, entry->sha1, entry->flag, cb_data);

Re: [PATCHv4 1/4] Refactor for_each_ref variants to use for_each_ref_in and avoid magic numbers

[Jakub Narebski]

This patch series would surely benefit from a cover letter...

Jamey Sharp <jamey@minilop.net> writes:

> From: Josh Triplett <josh@joshtriplett.org>
> 
> Several variants of the for_each_ref functions call do_for_each_ref with
> both a fixed string prefix and the hardcoded length of that prefix.
> Furthermore, for_each_ref and for_each_ref_submodule passed "refs/" but
> a length of 0, which caused do_for_each_ref to ignore the "refs/".
[...]

-- 
Jakub Narebski
Poland
ShadeHawk on #git