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

[Tanu Kaskinen]

On 04/02/2013 09:21 AM, David Henningsson wrote:
> On 03/30/2013 07:00 AM, Tanu Kaskinen wrote:
>> 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?

The plan is to delete the next branch after the release, so that's not 
an issue. The issue is that my intention was to do rebasing whenever the 
master branch is updated, so that the next branch would always be 
cleanly on top of the master branch.

The race condition is a valid point, even if problems are very unlikely. 
I don't really have strong arguments for why we must keep the next 
branch rebased on master. My reasoning was that it reduces the 
likelihood of difficult conflicts, but now that I think about it again, 
I'm not sure how true that is. We can at least try an approach where we 
don't do any rebasing (until we merge the next branch back to master 
after the release). If there are problems, we can evaluate whether the 
problems would be any smaller if the next branch was kept rebased on master.

In conclusion, I won't set up the update hook for now.

-- 
Tanu