> What's lacking is "why this is a good idea".
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.
--
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
