Re: Forcing --no-ff on pull

From: R. Tyler Ballance <tyler@slide.com>
Date: Dec 9, 2008, 10:38 UTC
Message-ID: <1228819087.18611.73.camel@starfruit.local>
In-Reply-To: <20081209191704.6117@nanako3.lavabit.com>

On Tue, 2008-12-09 at 19:17 +0900, Nanako Shiraishi wrote:

Show 9 quoted lines

> 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.

The first option (block) is not feasible as it will block the 40+ other developers from pushing code until LazyDeveloper sufficiently gets their crap together.

The second option is why I want to force --no-ff on *all* pulls if possible. With --no-ff we can simply `git revert -sn <hash> -m 1 && git commit -a` in order to back out A, B, C, D. With a true fast-forward, we've had to use git-rev-list(1) trickery and some bash scriptery to properly revert a series of commits from a given time frame from a given developer.

> If you forbid fast-forward merges, when they merge their successful
> experiment back to the original topic, it will leave an unwanted merge
> in the history.

I'm less concerned at this point, the company switched entirely to Git two weeks ago, with the history containing possible unwanted merges. I'm more concerned however with LazyDeveloper inadvertently polluting stable branches as LazyDeveloper does not yet fully grasp the concepts that Git offers

> 
> In other words, I do not think --no-ff is a right solution for the problem you are trying to solve.  Perhaps you would need a hook that prevents a merge from certain direction from taking place instead?

If you do have a better solution to this problem (I dislike git push -f origin[1]) I'm all ears, I'm more concerned with the end result at this point ;)

Cheers

[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".

-- 
-R. Tyler Ballance
Slide, Inc.