git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Marius Storm-Olsen <mstormo@gmail.com>
Cc: Michael Poole <mdpoole@troilus.org>,
	Eugene Sajine <euguess@gmail.com>,
	git@vger.kernel.org
Subject: Re: Git push over git protocol for corporate environment
Date: Thu, 1 Oct 2009 11:06:28 -0700	[thread overview]
Message-ID: <20091001180628.GQ14660@spearce.org> (raw)
In-Reply-To: <4AC44C55.6080807@gmail.com>

Marius Storm-Olsen <mstormo@gmail.com> wrote:
> Shawn O. Pearce said the following on 01.10.2009 02:06:
>> Michael Poole <mdpoole@troilus.org> wrote:
>>> (Others have mentioned Gerrit.  I use that at work, and my only
>>> major wish is that it had per-branch rather than per-project
>>> access controls.  It is a vast improvement over the Subversion
>>> system we had before.)
>>
>> You'll be happy to hear _everyone_ is demanding per-branch
>> controls, I have to do it before the end of the year, maybe even
>> before the end of the month...
>
> Ugh, any pointers on this one? Does this mean that you're planning to  
> add this sort of control in git itself, or just some way to facilitate  
> the setting of owner/group on individual ref files? What about packed  
> refs?

I guess you don't know how Gerrit Code Review works, or missed that
I was talking about Gerrit and not git.

Gerrit behaves like Gitosis, it owns the repositories under its care,
and (in general) nobody else is allowed to read or write to them
except the Gerrit daemon process.  That process is running JGit,
not git.git, which means I have full control over the entire code
that serves that repository.

We already have write level control to branches in that JGit has
per-ref hook support similar to what the update hook provides in git.
It doesn't actually use the update hook, its an interface API the
server implements and pushes down into the JGit library, and it has
more control over the response issued to the client, but we get the
same result.  I'm just missing a UI that allows an administrator to
configure that implementation's decision making on a per-ref basis.

We don't yet have read level control to read branches, but this
is fairly trivial to implement.  I just need an interface API
that can filter the refs before we advertise them to the client.
Given my expand refs protocal extension that I started working on
(but have not yet finished) I'd need something like that in JGit
anyway just to implement the expand refs behavior.  Teaching it to
further filter refs by who can read what is then trivial.

-- 
Shawn.

      reply	other threads:[~2009-10-01 18:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-30 23:13 Git push over git protocol for corporate environment Eugene Sajine
2009-09-30 23:23 ` David Brown
2009-09-30 23:43 ` Jakub Narebski
     [not found]   ` <00163623ac5d75929b0474e66b96@google.com>
2009-10-02 14:41     ` Eugene Sajine
2009-10-02 14:47       ` Shawn O. Pearce
2009-10-02 15:58         ` Eugene Sajine
2009-10-02 18:54       ` Ismael Luceno
2009-10-04 15:25     ` Jakub Narebski
2009-10-04 16:26       ` Matthieu Moy
2009-09-30 23:54 ` Michael Poole
2009-10-01  0:06   ` Shawn O. Pearce
2009-10-01  6:29     ` Marius Storm-Olsen
2009-10-01 18:06       ` Shawn O. Pearce [this message]

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=20091001180628.GQ14660@spearce.org \
    --to=spearce@spearce.org \
    --cc=euguess@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=mdpoole@troilus.org \
    --cc=mstormo@gmail.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).