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
