David Lightle <dlightle@xxxxxxxxx> writes: > In your above scenario with Alice & Bob, wouldn't that same issue come > up in _any_ rebase workflow (--ff-only)? From what I've read this is > a typical consequence of requiring fast-forward merges; to be > effective, the rebase step must be more likely to succeed in a time > window than for someone to have pushed additional changes (otherwise > you end up in a loop like above). But I don't believe that's > inherently any worse with the change I'm asking about which would > only take that existing flag (--ff-only) and additionally create an > actual merge commit when those conditions are present. True, but that does not change the fact that you would be adding _more_ code to support a workflow that we know to be bad. > In fact, I just noticed that GitLab has built in the functionality I'm > looking for even, which is what they call "Merge commit with > semi-linear history" but I'm asking whether direct support for this > approach would be reasonable. These approaches can all produce the > "untested merged product", but they support the way the users want to > use the system as well. I'm not saying any approach is right or wrong > as I'm not qualified enough to say. We, not being a for-profit entity, do not have a strong incentive to add features that encourages bad workflow to the users. Of course, we also do not necessarily stop them if users really want to shoot themselves in the foot ;-), but such a change would inevitably be of lower priority to us. -- 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