[Kde-scm-interest] Re: Request regarding Git branches

Ben Cooksley bcooksley at kde.org
Mon Dec 20 09:47:15 CET 2010


2010/12/20 Chani <chanika at gmail.com>:
> On December 19, 2010 21:52:42 Ian Monroe wrote:
>> On Sun, Dec 19, 2010 at 11:55, Mark Kretschmann <kretschmann at kde.org> wrote:
>> > On Sun, Dec 19, 2010 at 6:48 PM, Torgny Nyblom <kde at nyblom.org> wrote:
>> >> On Sun, 19 Dec 2010 18:39:52 +0100
>> >>
>> >> Mark Kretschmann <kretschmann at kde.org> wrote:
>> >>> Hey folks,
>> >>>
>> >>> I have a small request regarding git.kde.org, it resulted from a
>> >>> discussion with Chani:
>> >>>
>> >>> Problem is, we cannot currently force-push on branches, nor can we
>> >>> delete them. I can understand that this is done for safety reasons,
>> >>> but it does not fit everyone's work flow. E.g. I tend to rebase a lot,
>> >>> and that does not work without force pushing.
>> >>>
>> >>> So, Chani and I came up with this idea: We could allow force-pushing
>> >>> and deleting on branches (shares branches need communication anyway),
>> >>> but we could disallow it for master. This way, not much harm can be
>> >>> done, but it allows for a more flexible work flow.
>> >>>
>> >>>
>> >>> Thoughts?
>> >>
>> >> It would have to be a per branch setting as for instance KDE 4.7 will
>> >> probably be in a lot of git branches and quite some harm can be done
>> >> with force push/branch deletion there.
>> >
>> > My view is this: If you share a branch with others, you *need* to
>> > communicate anyway. I you just rebase it, of course that will do harm.
>> >
>> > So you don't rebase on branches that you want for cooperation, simple
>> > as that. I think that a "per branch" setting would cause a lot of
>> > work...
>>
>> Rebasing a 4.7 branch over master would be a horrible thing to have
>> happen. So it really can't be allowed for version branches.
>>
>
> some context:
> what *I* was thinking about was having two repos, one for release branches and
> the other for team branches and integration.

As I previously noted on the Plasma ml, sysadmin hasn't made a
decision on team clones...

>
> I... don't remember whether that's something markey is interested in, though.
> *shrug*

If you were using a clone (or scratch repo), you would be subject to
the following access controls:

repo scratch/CREATOR/[a-zA-Z0-9][a-zA-Z0-9_\.\-]+[a-zA-Z0-9]
    C                   = @all
    RW+CD         = CREATOR
    RW                = @all

repo clones/[a-zA-Z0-9][a-zA-Z0-9_\.\-]+[a-zA-Z0-9]/CREATOR/[a-zA-Z0-9][a-zA-Z0-9_\.\-]+[a-zA-Z0-9]
    RW+CD         = CREATOR
    RW                 = @all

Standard repositories are subject to:

repo <reponame>
    RWCD               = <maintainer>
    RW                    = @all

This is (part of) the access control that Gitolite, the software
powering git.kde.org is using.

C           = Create repository
RW        = Read, Write (excludes force)
RWCD   = Read, Write (excludes force), Create (refs), Delete (refs)
RW+CD = Read, Write (including force), Create (refs), Delete (refs)

>
> --
> Chani
> http://chani.ca
>
> _______________________________________________
> Kde-scm-interest mailing list
> Kde-scm-interest at kde.org
> https://mail.kde.org/mailman/listinfo/kde-scm-interest
>
>

Regards,
Ben Cooksley
KDE Sysadmin


More information about the Kde-scm-interest mailing list