Supporting Namespaces in cgit

Daniel Silverstone dsilvers at digital-scurf.org
Mon May 9 23:54:44 CEST 2016


On Mon, May 09, 2016 at 22:31:37 +0100, John Keeping wrote:
> Implementation-wise, it looks like using a namespace should just be a
> matter of setting GIT_NAMESPACE in the environment near the top of
> cgit.c::prepare_repo_cmd().

This is certainly the basic starting point.

> Discovering namespaces is more interesting, since we can't know what
> exactly is a namespace.  For example, if we have:
> 
> 	refs/namespaces/foo/bar/baz
> 
> is the namespace "foo" or "foo/bar"?  Maybe checking for "heads" and
> "tags" subdirectories is enough, but I'm not familiar enough with
> namespaces to know if those will definitely exist, and obviously users
> can create or delete any directories anywhere in the hierarchy.

I'd not attempt to discover namespaces.  I think if you're given a namespace to
use in the repo stanza you use it, otherwise current behaviour prevails.

> Also, any attempt to discover namespaces during automated repository
> discovery (i.e. cgitrc's "scan-tree") is likely to be quite expensive
> with reading packed-refs and the whole loose refs tree.  However, it
> sounds like Gitano probably generates an explicit repository list, in
> which case a "repo.namespace" config key should be usable.

Yes, that's the intended behaviour.  I wouldn't expect cgit to be able to
invent namespace understanding out of nothing.

> If we can indeed ignore any attempt to discover namespaces and just use
> "repo.namespace", is it enough to add that config value to
> "struct cgit_repo" and then pass it to setenv() in prepare_repo_cmd()?

This is a necessary start, but it is not sufficient.  Elsewhere in the codebase
changes will need to be made to use namespace aware ref iteration among other
things.  In addition, if we wish to support agefile per-namespace then we need
a repo.agefile option which can override the global option.  There may be more
but right now I don't have them to mind because I've not fully scoured the
codebase.

If you think it's worth our while implementing a proof-of-concept patch series
then we'll give it a go.  I'm quite excited about being able to do this because
it'll open up so many interesting options for me when Gitano can ACLs which are
namespace aware :-)

D.

-- 
Daniel Silverstone                         http://www.digital-scurf.org/
PGP mail accepted and encouraged.            Key Id: 3CCE BABE 206C 3B69


More information about the CGit mailing list