Lukas Fleischer <[email protected]> writes:
> 2. transfer.hideRefs and receive.hideRefs do not seem to work with Git
> namespaces in general. show_ref_cb() replaces each ref outside the
> current namespace with ".have" before passing it to show_ref() which
> in turn performs the ref_is_hidden() check. This has the nice side
> effect that receive.hideRefs=.have does exactly what I want, however
> it also means that hideRefs feature does not allow for excluding only
> specific tags outside the current namespace. Is that intended? Can we
> rely on Git always looking for ".have" in the hideRefs list in this
> case?
When I asked 'Is transfer.hiderefs insufficient?', I wasn't
expecting it to be usable out of box. It was a suggestion to build
on top of it, instead of adding a parallel support for something
specific to namespaces.
For example, if the problem is that you cannot tell ref_is_hidden()
what namespace the ref is from because it is called after running
strip_namespace(), perhaps you can find a way to have the original
"namespaced ref" specified on transfer.hiderefs and match them?
Then in repository for project A, namespaced refs for project B can
be excluded by specifying refs/namespaces/B/* on transfer.hiderefs.
Perhaps along the lines of this?
builtin/receive-pack.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index bcb624b..db0a99d 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -221,6 +221,15 @@ static void show_ref(const char *path, const unsigned char
*sha1)
static int show_ref_cb(const char *path, const struct object_id *oid, int
flag, void *unused)
{
+ const char *ns = get_git_namespace();
+
+ /*
+ * Give the "hiderefs" mechanism a chance to inspect and
+ * reject the namespaced ref itself.
+ */
+ if (ns[0] && ref_is_hidden(path))
+ return 0;
+
path = strip_namespace(path);
/*
* Advertise refs outside our current namespace as ".have"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
