List for cgit developers and users
 help / color / mirror / Atom feed
From: john at keeping.me.uk (John Keeping)
Subject: Supporting Namespaces in cgit
Date: Mon, 9 May 2016 22:31:37 +0100	[thread overview]
Message-ID: <20160509213137.GE14612@serenity.lan> (raw)
In-Reply-To: <20160509203424.GB30631@somnambulist.local>

On Mon, May 09, 2016 at 09:34:24PM +0100, Daniel Silverstone wrote:
> One of the projects I am involved with is called Gitano[1] and is a Git server
> along the lines of Gitolite or Gitosis, but not along the lines of Gitlab or
> Gitorious.  Among various technologies developed by other projects, we
> recommend the use of CGit for visualising the Git repositories hosted in a
> Gitano instance; and we have been very pleased with CGit in the three or
> four years we've been using it.
> 
> We have recently been looking at ways to support server-side repository forks
> in Gitano and how we might use namespaces to support that.  In addition that
> led to us thinking about how we could segregate Gitano's administration refs
> into a namespace to keep things cleaner.  However if we were to use server-side
> namespaces for that, then we would need to ensure our chosen web visualisation
> tool (CGit) was able to deal with it.
> 
> An examination of the code (thorough, but admittedly a while ago) failed to
> find any support for Git namespaces in CGit, but I wondered firstly if
> namespaces had ever been considered for support in CGit?  If not yet
> considered, would support for namespaces be something that the CGit project
> might entertain?  We would be very prepared to do a first pass set of patches,
> or indeed a design document first if that were desirable; but given our
> relative inexperience in the CGit codebase we would very much appreciate
> pointers and assistance from the CGit community.
> 
> Obviously, if namespace support is not something that the CGit community wants
> to see done then we will have to rethink some of our backend design decisions.
> Similarly, if it's interesting but there is no intention to make a CGit release
> within the timeframe we'd be working to (approx. November time at the latest)
> then we'll need to think again.
> 
> I appreciate this is a fairly content-free mail that seems to be asking so much
> and offering very little, so in brief summary:
> 
> 1. We'd like CGit to support namespaces on a per-repo basis
> 2. We're prepared to head up the design and/or implementation of this
> 3. But only if the CGit community thinks this is at least possible to get
>    merged into a release the near future (next 6 months or so).
> 
> I look forward to your opinions, even if they're in the negative.

I'm curious what you expect the UI for this to look like.  Would
namespaces appear under the repository in the URL?  If so, what does the
base repository look like?  (Although after I finished thinking this
through and writing the rest of the email maybe this doesn't actually
matter - see the last paragraph.)

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().

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.

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.

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()?


  reply	other threads:[~2016-05-09 21:31 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 [this message]
2016-05-09 21:54   ` dsilvers
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=20160509213137.GE14612@serenity.lan \
    --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).