Quoting "R. Tyler Ballance" <tyler@xxxxxxxxx>: > 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
