[pulseaudio-discuss] Update hook for selectively allowing non-fast-forward updates

[David Henningsson]

On 03/30/2013 07:00 AM, Tanu Kaskinen wrote:
> On Saturday, March 30, 2013 07:16:36 AM David Henningsson wrote:
>> On 03/29/2013 12:26 PM, Tanu Kaskinen wrote:
>>> Hi,
>>>
>>> I tried to rebase the next branch on master, but pushing a
>>> non-fast-forward update failed, because the receive.denyNonFastforwards
>>> option is set to true. If there are no objections, I'll soon remove that
>>> option and replace it with an update hook that will by default reject
>>> non-fast-forward updates, but will allow them for explicitly configured
>>> branches. The update hook script is attached.
>>
>> Why? In case of the rebase you just use the -f flag.
>>
>>   From http://git-scm.com/book/ch7-1.html:
>>
>> receive.denyNonFastForwards
>>
>> If you rebase commits that you’ve already pushed and then try to push
>> again, or otherwise try to push a commit to a remote branch that doesn’t
>> contain the commit that the remote branch currently points to, you’ll be
>> denied. This is generally good policy; but in the case of the rebase,
>> you may determine that you know what you’re doing and can force-update
>> the remote branch with a -f flag to your push command.
>
> I'm well aware of the -f flag. That paragraph you quoted talks about the
> default behavior. The next paragraph tells how to change the default behavior
> with denyNonFastForwards, so that also forced pushes are denied:
>
>          To disable the ability to force-update remote branches to
>          non-fast-forward references, set receive.denyNonFastForwards:
>
>          $ git config --system receive.denyNonFastForwards true
>

Ah, sorry for not reading enough. I'd like the most secure option 
possible, given all the man hours we put into this project.

And it looks to me like the "next" branch would be subject to race 
conditions here (i e two users changing it in parallel, overwriting each 
other's changes)?

Would it be possible instead to rename the old next branch, thus making 
the "next" branch name available? Or use next-4.0, next-5.0 etc?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic