colin@xxxxxxxxxxx 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. -- 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
