List for cgit developers and users
 help / color / mirror / Atom feed
From: dsilvers at digital-scurf.org (Daniel Silverstone)
Subject: Supporting Namespaces in cgit
Date: Mon, 9 May 2016 22:54:44 +0100	[thread overview]
Message-ID: <20160509215444.GD30631@somnambulist.local> (raw)
In-Reply-To: <20160509213137.GE14612@serenity.lan>

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


  reply	other threads:[~2016-05-09 21:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09 20:34 dsilvers
2016-05-09 21:31 ` john
2016-05-09 21:54   ` dsilvers [this message]
2016-05-10 13:21     ` john
2016-06-25 15:46       ` richard.maw
2016-06-26  0:44         ` richard.maw

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160509215444.GD30631@somnambulist.local \
    --to=cgit@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).