Re: Forcing --no-ff on pull

From: Nanako Shiraishi <nanako3@lavabit.com>
Date: Dec 9, 2008, 10:17 UTC
Message-ID: <20081209191704.6117@nanako3.lavabit.com>
In-Reply-To: <1228815240.18611.48.camel@starfruit.local>

Quoting "R. Tyler Ballance" <tyler@slide.com>:

Show 5 quoted lines

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

If you mean that the user merged branches in a wrong direction, how does it help her avoid such a mistake to unconditionally forbid fast-forward merges?  Doesn't people often do:

 Start on a topic branch, have a potentially bright idea...
 % git checkout -b experiment
 Hack on experiment branch.
 Happy because it indeed was an excellent idea.
 % git checkout topic
 % git pull . experiment
 % git branch -d experiement

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.

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?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/