Re: Forcing --no-ff on pull

From: Stephen Haberman <stephen@exigencecorp.com>
Date: Dec 10, 2008, 19:07 UTC
Message-ID: <20081210130738.0662082f.stephen@exigencecorp.com>
In-Reply-To: <alpine.LNX.1.00.0812091651360.19665@iabervon.org>

On Tue, 9 Dec 2008 17:32:36 -0500 (EST) Daniel Barkalow <barkalow@iabervon.org> wrote:

Show 23 quoted lines

> > At this point, QA is involved and what can happen is that QA realizes
> > that this code is *not* stable and *never* should have been brought into
> > the stable branch.
>
> How do you prevent the (IMHO more likely) case of:
> 
> % git checkout -b project
> % git checkout stable
> <fix some bug in stable>
> % git commit -a
> <forget to switch branches back>
> <work>
> % git commit -am "A"
> <work>
> % git commit -am "B"
> ...
> % git push origin stable
> 
> That is, the developer makes a whole bunch of inappropriate commits on 
> their stable branch instead of their project branch and then pushes it out 
> (perhaps as part of a push rule, or thinking only the bug fix went there). 
> I suspect that "pull" step there isn't the point where things are going 
> wrong.

Well, two things:

1) The hook script at [1] really would prevent this from getting published.
   Although it only looks for "stable"--if you have per-team stable branches,
   you might need to match on "*-stable" or something like that. But it does
   (copy/paste from [1]):

# * stable must move by only 1 commit-per-push # * the stable commit must have 2 and only 2 parents # * The first parent must be the previous stable commit # * The second parent is the tip of the candidate branch being released # * the stable commit must have the same contents as the candidate tip # * Any merge conflicts should have been resolved in the candidate tip # by pulling stable into the candidate and having qa/tests done--pulling # candidate into stable should then apply cleanly

So, no fast forwards, no direct commits, only "good"/empty merges of topic branches can move stable. Anything else is rejected and LazyDev has to try again.

2) As far as "pull" isn't where things are going wrong, that is not
   entirely true, as even with the server-side enforcement like [1],
   I think you'd still like to help LazyDev out and have `git pull`
   "just work" for your given setup. Especially if you don't have full
   management buy-in to git, pacifying LazyDev's can be necessary.

- Stephen

1: http://github.com/stephenh/gc/tree/master/server/update-stable