Re: [RFC/PATCH] Fast forward strategies allow, never, and only

Seconded. A long time ago (and I'm too lazy to find a link), Linus explained why disabling fast-forward merges was almost always a Bad Idea, and nobody has come up with a good reason why you'd want one since.

But from memory, suppose that you have two developers, each working on their own branch:

     a--a--a <-- A's head
    /
o--o
    \
     b--b--b <-- B's head

Then suppose that they merge back and forth to get to the same state. With fast-forward merges, it will go like this:

A merges from B:
     a--a--a
    /       \
o--o         o <-- A's head
    \       /
     b--b--b <-- B's head

Then B merges from A:
     a--a--a
    /       \
o--o         o <-- Both heads
    \       /
     b--b--b

And look, they are in sync and can go on to develop from a common base version. Future merges will do nothing.

If, instead, you have every merge generate a commit, then you get:
     a--a--a
    /       \
o--o         o <-- A's head
    \       / \
     b--b--b---o <-- B's head

     a--a--a
    /       \
o--o         o---o <-- A's head
    \       / \ /
     b--b--b---o <-- B's head

     a--a--a
    /       \
o--o         o---o <-- A's head
    \       / \ / \
     b--b--b---o---o <-- B's head

.. and it never ends. All of the merged commits are identical trees, but if you insist on creating a new commit object each time, you can generate an infinite number of bogus commits, and more to the point, A and B will never actually agree on the current HEAD commit.

With more developers, you can make even more of a mess.

What use does the "--ff=never" option have except to generate this cruft? Flexibility is useful only as long as it provides the ability to do something desirable. There's no point to having a button that should never be pushed.