threads / rfc / 26303

[RFC] Per-branch receive.* settings

Subject: [RFC] Per-branch receive.* settings

## tl;dr

2 messages between Jan 18, 2011 and Jan 19, 2011.

replies: 1people: 2as markdown or json

Ævar Arnfjörð Bjarmason· Jan 18, 2011, 23:07 UTC · lore
Currently you can do in your server's git config:
    [receive]
        denyDeletes = true
        denyNonFastForwards = true

But for most servers that's not what you want, you actually want to deny those things to the master branch, but allow people to have their private topic branches that they can reset. So how about allowing:

    [receive]
        denyDeletes = false
        denyNonFastForwards = false
    [branch "master"]
        denyDeletes = true
        denyNonFastForwards = true
I.e. have a per-branch setting that overrides the global setting?
(Of course ideally this would be:
    "branch.master.receive.{denyDeletes,denyNonFastForwards}"
But the *.ini format can only have a depth of three, so it has to be:
    "branch.master.{denyDeletes,denyNonFastForwards}"
Or perhaps:
    "branch.master.receive-{denyDeletes,denyNonFastForwards}"

Anyway, I can code this up if there's interest in it. This could also be done with a .git/hooks/update hook, but IMO it's better to have this as a documented setting for the most common things you want to deny/allow.

Junio C Hamano· Jan 19, 2011, 00:12 UTC · re: Ævar Arnfjörð Bjarmason · lore

Re: [RFC] Per-branch receive.* settings

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 17 quoted lines
> Currently you can do in your server's git config:
>
>     [receive]
>         denyDeletes = true
>         denyNonFastForwards = true
>
> But for most servers that's not what you want, you actually want to
> deny those things to the master branch, but allow people to have their
> private topic branches that they can reset. So how about allowing:
>
>     [receive]
>         denyDeletes = false
>         denyNonFastForwards = false
>
>     [branch "master"]
>         denyDeletes = true
>         denyNonFastForwards = true

While this would not be better than having no such feature, if you are talking about allow(ing) "people", I doubt this would scale very well.

I wonder some globbing with site-specific naming convention would be more scalable:

	[receive]
        	denyDeletes = refs/heads/* && !refs/heads/*/*
                denyNonFastForwards = refs/heads/* && !refs/heads/*/*

And in the meantime, of course you can use your update hook, mimicking various examples, ranging from contrib/hooks/update-paranoid, Documentation/howto/update-hook-example.txt, and hooks/update.sample.

← back to recent threads