David Lightle <dlightle@xxxxxxxxx> writes: > I know that I have read that --ff-only and --no-ff are contradictory, > but I believe that is somewhat ambiguously correct -- I believe the > two flags contradict in the sense of "what to do with the merge > commit", but not necessarily on the "when it can be done". Traditionally we have mildly suggested against making otherwise needless merge commit with "--no-ff". We also have suggested against keeping the history too linear, not because linear history is bad, but because it will require rebasing soon before pushing out your changes [*1*]. I personally would feel that what you seem to be aiming for is the worst of both worlds in the sense that contributors are still forced to rebase immediately before pushing out, which leads to insufficiently tested version landing on truck, and at the same time forcing the resulting history to have otherwise needless merges (the latter is probably a much lessor of the two sins). However, Git as a tool is not opinionated strongly enough to make it hard to do these two things (independently). I do not think it is unreasonable to add a new mode of "merge" that rejects a resulting history that is not shaped the way you like. So far the command rejected --ff-only and --no-ff given together, so if an updated Git starts taking them together and creating a needless real merge and failing only when the first parent does not fast-forward to the second parent, nobody's existing workflow would be broken. Having said that, you need to think things through. Sample questions you would want to be asking yourself are (not exhaustive): - What is your plan to _enforce_ your project participants to use this new mode of operation? - Do you _require_ your project participants to always pass a new option to "git merge" or "git pull"? - Do you force them to set some new configuration variables? - Do you trust them once you tell them what to do? - How will your project's trunk get their changes? - How you prevent some participants who misunderstood your instructions from pushing an incorrectly shaped history to your project? If they are eventually pushing the result to a central repository and that is how the project's overall history advances, then the most reliable mechanism that is least limiting to your users is pre-receive hook at that central repository that ensures the shape of the history being pushed to update the branches. You walk the first-parent chain of the commits and ensure all the commits are merges, and for each of these merges, its second parent is a descendant of its first parent. Otherwise you reject their push. That way, your users can make normal merges while trying their changes locally all they want without straightjacket. Only when they prepare the final history to be placed at the tip of the project's official history, they need to make sure that the history is shaped as you specified. [Footnote] *1* Your changes before rebasing may have seen enough testing in one context (i.e. built on older base), but "rebase immediately before push to ensure fast-forward" will force you to publish a version that by definition will have little or no testing, which may or may not work well with a different context. -- 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