Re: Forcing --no-ff on pull

From: Boyd Stephen Smith Jr. <bss03@volumehost.net>
Date: Dec 9, 2008, 14:36 UTC
Message-ID: <200812090836.31012.bss03@volumehost.net>
In-Reply-To: <1228819087.18611.73.camel@starfruit.local>

On Tuesday 09 December 2008, "R. Tyler Ballance" <tyler@slide.com> wrote about 'Re: Forcing --no-ff on pull':

Show 44 quoted lines

>On Tue, 2008-12-09 at 19:17 +0900, Nanako Shiraishi wrote:
>> Quoting "R. Tyler Ballance" <tyler@slide.com>:
>> > The most common use-case involves a user merging a project branch
>> > into a stabilization branch (`git checkout stable && git pull .
>> > project`) in such a way that no merge commit is generated. Of course,
>> > without thinking they'll push these changes up to the centralized
>> > repository. Not 15 minutes later they realize "ruh roh! I didn't want
>> > to do that"
>>
>> Why does the user not want to fast-forward, if the merge she wants to
>> do is actually a fast-forward?
>
>I agree with you, this is more about preventing coworkers who are too
>lazy to understand the entirety of what they're doing from hurting the
>workflow of "the rest of us". It's a technically solution to a people
>problem (I understand technology far more than people ;))
>
>Consider the following scenarion:
>  % git checkout -b project
>  % <work>
>  % git commit -am "A"
>  % <work>
>  % git commit -am "B"
>  % <work>
>  % git commit -am "C"
>  % <work>
>  % git commit -am "D"
>  % git checkout stable
>  % git pull . project
>  % <fast-forward>
>  % git push origin stable
>
>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.
>
>Now we have two options "block" the stable branch until LazyDeveloper
>makes the appropriate changes to stabilize the branch again *OR* back
>out LazyDeveloper's changes (A, B, C, D) and beat them up in the
>alleyway :)
>
>Given the nature of our work, we have a stable branch per-team, and one
>funneling stable branch for the entire company (master), that branch
>being used to push the live web site with.

In the words of 4chan: "You're doing it wrong."

If QA decides what is appropriate for the stable branch, only QA should be pushing to stable (not just any dev. or team) and this should be enforced.

QA can retrieve commits from individual developers or teams, via email, by pulling from their private repositories, or pulling from "private" branches in the public repository. The last seems most appropriate for your organization.

I think a better workflow would be for developers to pull from "stable" but push to "<username>-tbr" (TBR = to be reviewed). Team leads would review code by pulling from "<developer>-tbr" and if it looked okay would push to "<team>-tbt" (TBT = to be tested). Of course, if they needed to originate a change they could pull from "stable" instead of any individual developer's branch. QA would pull from "<team>-tbt", build, deploy, and test and if it's good push to "stable". Some automated process would watch "stable" and update production from it.

This way bad commits are generally rejected before they become part of history. Hooks can be used to notify team leads and QA about new commits for review or testing.

Show 6 quoted lines

>[1] We've stressed with our developers as much as possible that the
>"origin" repository is to remain" pristine", that every action should be
>"auditable" insofar that if you rollback a change, we want to see a
>Revert commit, merges should create merge commits to where we can replay
>or unwind the revision history correctly at any point in time or slice
>of time. I *really* don't want "origin" to "lose commits".

To this end, I'd probably forbid non-ff commits to "stable".

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/