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

[Bruce Stephens <bruce.stephens@isode.com>]

colin@horizon.com writes:

>> What's lacking is "why this is a good idea".

[...]

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

IIUC what the new option is about is (optionally) forbidding merges.
So it's orthogonal to the existing --no-ff and --ff merge options.

So you *don't* get that kind of criss-crossing: if you've got a local
commit, the merge fails.  So you have to use rebase.  So it's not
making the history more complex, it's linearizing it.

Now surely you don't always want to do that, but it seems like a very
convenient option that you can generally have on, and switch off when
you intend to do a merge.