Re: Fast-forward able commit, otherwise fail

David Lightle <dlightle@gmail.com> writes:

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.