denying branch creation in a shared repository

denying branch creation in a shared repository

[Mohit Aron]

Hello,

I'm setting up a shared repository and I'd like to prevent users from
creating branches in it (they can of course create local branches in
their own clone of this repository). How can I accomplish this ? I
looked at 'git help config' and it seems I need something similar to
the parameter receive.denyDeletes - this prevents deletion of
branches.


- Mohit

Re: denying branch creation in a shared repository

[Sitaram Chamarty]

On Mon, Oct 19, 2009 at 2:02 PM, Mohit Aron <mohit.aron@gmail.com> wrote:
> Hello,
>
> I'm setting up a shared repository and I'd like to prevent users from
> creating branches in it (they can of course create local branches in
> their own clone of this repository). How can I accomplish this ? I
> looked at 'git help config' and it seems I need something similar to
> the parameter receive.denyDeletes - this prevents deletion of
> branches.

That was the main reason I wrote gitolite
(http://github.com/sitaramc/gitolite), though now it does a heck of a
lot more than just that.

Scroll down a bit on that page for the README.

People have said pretty nice things about it on #git, and (subject to
being in India time zone and the day job and all) I make sure I help
out as much as I can.  Email or #git, both are fine.

Being somewhat familiar with ssh and authkeys is good.  Otherwise,
*please* be sure to read
http://sitaramc.github.com/0-installing/9-gitolite-basics.html for
background

Re: denying branch creation in a shared repository

[Björn Steinbrink]

On 2009.10.19 01:32:24 -0700, Mohit Aron wrote:
> I'm setting up a shared repository and I'd like to prevent users from
> creating branches in it (they can of course create local branches in
> their own clone of this repository). How can I accomplish this ? I
> looked at 'git help config' and it seems I need something similar to
> the parameter receive.denyDeletes - this prevents deletion of
> branches.

You could write a pre-receive or update hook (depending on whether you
want the whole push to fail, or just the branch head creation, see
githooks(5)).

If a ref is created, the old value is 40 0 (just zeros, forty of them).
And if the refname starts with refs/heads/, then a branch head is being
created. And in that case, you could refuse the push.

Björn

Re: denying branch creation in a shared repository

[Johannes Schindelin]

Hi,

On Mon, 19 Oct 2009, Mohit Aron wrote:

> I'm setting up a shared repository and I'd like to prevent users from 
> creating branches in it (they can of course create local branches in 
> their own clone of this repository). How can I accomplish this ? I 
> looked at 'git help config' and it seems I need something similar to the 
> parameter receive.denyDeletes - this prevents deletion of branches.

The easiest way to accomplish things is to look who had the same problem 
and solved it:

http://repo.or.cz/w/repo.git?a=blob;f=update-hook;h=98b419ecad61f6c80f;hb=6f92e96db0d605bed50db99029172607af301792#l16

Hth,
Dscho

Re: denying branch creation in a shared repository

[Howard Miller]

Hi,

I'm quite interested in this too but I can't see what that patch does
at all. I'm unsure what the 'mob' account is but a search suggests
it's something to do with anonymous access, which doesn't seem to make
any sense.

Can you explain?

Thanks!

2009/10/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Mon, 19 Oct 2009, Mohit Aron wrote:
>
>> I'm setting up a shared repository and I'd like to prevent users from
>> creating branches in it (they can of course create local branches in
>> their own clone of this repository). How can I accomplish this ? I
>> looked at 'git help config' and it seems I need something similar to the
>> parameter receive.denyDeletes - this prevents deletion of branches.
>
> The easiest way to accomplish things is to look who had the same problem
> and solved it:
>
> http://repo.or.cz/w/repo.git?a=blob;f=update-hook;h=98b419ecad61f6c80f;hb=6f92e96db0d605bed50db99029172607af301792#l16
>
> Hth,
> Dscho
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: denying branch creation in a shared repository

[Johannes Schindelin]

Hi,

first, if you want to be taken seriously, you might want to avoid to 
top-post.

Second, do diligent research (e.g. on the 'mob' user).

On Mon, 19 Oct 2009, Howard Miller wrote:

> I'm quite interested in this too but I can't see what that patch does at 
> all. I'm unsure what the 'mob' account is but a search suggests it's 
> something to do with anonymous access, which doesn't seem to make any 
> sense.

If this trivial script (_not_ a patch! This should be obvious at first 
sight) does not make any sense to you, I fear you will not be able to use 
hooks to do what you want to do.

> Can you explain?

Yes.

The 'mob' user (who is password-less) can push to the 'mob' branch _iff_ 
that exists.  IOW a user of repo.or.cz can decide to let random people to 
push commits by creating the 'mob' branch and adding the 'mob' user to the 
pushers.

The first part of the hook (as you can see from the pretty helpful error 
messages it outputs) is about denying to push to anything but the mob 
branch.

The second part is much more interesting in the context of this thread 
(and I would expect anyone capable of reading shell scripts to see that 
readily), because it denies the 'mob' user to _create_ the 'mob' branch.  
See line 16ff.

So the point is: the update hook gets a "$2" = 0000... in case a branch is 
about to be created, and the hook can prevent that by exiting with a 
non-zero exit code.

Hth,
Dscho

Re: denying branch creation in a shared repository

[Howard Miller]

Mmm....

Thanks for the helpful reply Johannes. Perhaps you should do diligent
research into mail software that folds quoted text for you. There's a
company called Google you might have heard of. Just a thought.

On the other hand if you can't be bothered making a helpful reply
rather than a rude one perhaps simply not writing anything at all
would, at the very least, leave us absolutely no worse off. Just the
opinion of someone not to be taken seriously.... of course!

Howard

2009/10/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> first, if you want to be taken seriously, you might want to avoid to
> top-post.
>
> Second, do diligent research (e.g. on the 'mob' user).
>
> On Mon, 19 Oct 2009, Howard Miller wrote:
>
>> I'm quite interested in this too but I can't see what that patch does at
>> all. I'm unsure what the 'mob' account is but a search suggests it's
>> something to do with anonymous access, which doesn't seem to make any
>> sense.
>
> If this trivial script (_not_ a patch! This should be obvious at first
> sight) does not make any sense to you, I fear you will not be able to use
> hooks to do what you want to do.
>
>> Can you explain?
>
> Yes.
>
> The 'mob' user (who is password-less) can push to the 'mob' branch _iff_
> that exists.  IOW a user of repo.or.cz can decide to let random people to
> push commits by creating the 'mob' branch and adding the 'mob' user to the
> pushers.
>
> The first part of the hook (as you can see from the pretty helpful error
> messages it outputs) is about denying to push to anything but the mob
> branch.
>
> The second part is much more interesting in the context of this thread
> (and I would expect anyone capable of reading shell scripts to see that
> readily), because it denies the 'mob' user to _create_ the 'mob' branch.
> See line 16ff.
>
> So the point is: the update hook gets a "$2" = 0000... in case a branch is
> about to be created, and the hook can prevent that by exiting with a
> non-zero exit code.
>
> Hth,
> Dscho
>
>

Re: denying branch creation in a shared repository

[Howard Miller]

And... I instantly have to apologise..  With wonderful irony,
Googlemail folded the helpful bit of your reply leaving just the
(apparently) unhelpful bit.

(Crawls under nearest rock).

2009/10/19 Howard Miller <howard@e-learndesign.co.uk>:
> Mmm....
>
> Thanks for the helpful reply Johannes. Perhaps you should do diligent
> research into mail software that folds quoted text for you. There's a
> company called Google you might have heard of. Just a thought.
>
> On the other hand if you can't be bothered making a helpful reply
> rather than a rude one perhaps simply not writing anything at all
> would, at the very least, leave us absolutely no worse off. Just the
> opinion of someone not to be taken seriously.... of course!
>
> Howard
>
> 2009/10/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> Hi,
>>
>> first, if you want to be taken seriously, you might want to avoid to
>> top-post.
>>
>> Second, do diligent research (e.g. on the 'mob' user).
>>
>> On Mon, 19 Oct 2009, Howard Miller wrote:
>>
>>> I'm quite interested in this too but I can't see what that patch does at
>>> all. I'm unsure what the 'mob' account is but a search suggests it's
>>> something to do with anonymous access, which doesn't seem to make any
>>> sense.
>>
>> If this trivial script (_not_ a patch! This should be obvious at first
>> sight) does not make any sense to you, I fear you will not be able to use
>> hooks to do what you want to do.
>>
>>> Can you explain?
>>
>> Yes.
>>
>> The 'mob' user (who is password-less) can push to the 'mob' branch _iff_
>> that exists.  IOW a user of repo.or.cz can decide to let random people to
>> push commits by creating the 'mob' branch and adding the 'mob' user to the
>> pushers.
>>
>> The first part of the hook (as you can see from the pretty helpful error
>> messages it outputs) is about denying to push to anything but the mob
>> branch.
>>
>> The second part is much more interesting in the context of this thread
>> (and I would expect anyone capable of reading shell scripts to see that
>> readily), because it denies the 'mob' user to _create_ the 'mob' branch.
>> See line 16ff.
>>
>> So the point is: the update hook gets a "$2" = 0000... in case a branch is
>> about to be created, and the hook can prevent that by exiting with a
>> non-zero exit code.
>>
>> Hth,
>> Dscho
>>
>>
>

Re: denying branch creation in a shared repository

[Thomas Rast]

Howard Miller wrote:
> 2009/10/19 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >
> > first, if you want to be taken seriously, you might want to avoid to
                                   ^^^^^^^^^
> > top-post.
> 
> Thanks for the helpful reply Johannes. Perhaps you should do diligent
> research into mail software that folds quoted text for you. There's a
> company called Google you might have heard of. Just a thought.

It really is about the "seriously".  If you don't, you'll get your
mail outright ignored.

Many of us get lots[1] of mail per day, and have no time nor will to
scroll around in the message reading long (untrimmed) quoted parts
that are out of order, let alone click around in the corresponding
thread to remember the context.  If you want your mail to be read, you
should take some time to make it *easy* to read on its own.


[1] I'm luckily not one of them, but I hear high-profile project
maintainers get hundreds.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: denying branch creation in a shared repository

[Howard Miller]

>
> Many of us get lots[1] of mail per day, and have no time nor will to
> scroll around in the message reading long (untrimmed) quoted parts
> that are out of order, let alone click around in the corresponding
> thread to remember the context.  If you want your mail to be read, you
> should take some time to make it *easy* to read on its own.
>

I forgot and I apologise unreservedly. I am in a similar position on
other projects although we use web forums which makes it easier. I
certainly don't want to get into that argument though. I struggle a
great deal to be nice to people who haven't made any kind of effort to
even ask a sensible question so I do understand. The challenge is to
think someone is stupid yet to manage a polite, constructive and
non-arrogant reply (or just say nothing if you can't). At least web
forums have emoticons - a smiley fixes everything!!

Gentlemen... keep up the good work. Even an idiot like me thinks that
git is a fantastic project. It has saved me hours of pain and effort.

Re: denying branch creation in a shared repository

[Mohit Aron]

>
> That was the main reason I wrote gitolite
> (http://github.com/sitaramc/gitolite), though now it does a heck of a
> lot more than just that.
>

That's great. You might want to consider making it a deb package
that's available from one of the Ubuntu/Debian repositories. An apt
search on Ubuntu 9.10 doesn't reveal it. I usually shy away from
installing software on my machines that is not automatically managed.


- Mohit

Re: denying branch creation in a shared repository

[Sitaram Chamarty]

On Mon, Oct 19, 2009 at 10:13 PM, Mohit Aron <mohit.aron@gmail.com> wrote:
>>
>> That was the main reason I wrote gitolite
>> (http://github.com/sitaramc/gitolite), though now it does a heck of a
>> lot more than just that.
>>
>
> That's great. You might want to consider making it a deb package
> that's available from one of the Ubuntu/Debian repositories. An apt
> search on Ubuntu 9.10 doesn't reveal it. I usually shy away from
> installing software on my machines that is not automatically managed.

There are a couple of answers to this:

(1) I'm not really a debian guy, and definitely not ubuntu.  My distro
of choice for nearly 10 years has been Mandriva :-)

(2) gitolite's second reason for existence [after the one in this
thread] is the need to install something on machines where you do
*not* have root, can't create another user, etc etc.  There was a
Solaris 9 on which I couldn't install python-setuptools, and so no
gitosis :-(

Regardless of all that, someone is working on it...
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550817

I respect your inclination to shy away; I do the same for pretty much
everything except git itself and one or two others.

But if you don't mind looking through the documentation (browse it
directly on github; it'll render the markdown properly, though the
plain text is quite readable too), you may be able to better decide if
you want to use it despite this limitation.

Regards,

Sita