From: Nanako Shiraishi Date: Tue, 09 Dec 2008 10:17:04 GMT Subject: Re: Forcing --no-ff on pull Message-ID: <20081209191704.6117@nanako3.lavabit.com> In-Reply-To: <1228815240.18611.48.camel@starfruit.local> Quoting "R. Tyler Ballance" : > 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/