Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > It's clear --ff doesn't imply a merge, so we shouldn't act as if it was. Do you specifically mean --ff, or do you talk collectively about anything that goes in opt_ff in the C code? The "--ff" option means "we are allowing fast-forward, so please do not make new commit object unnecessarily, but it is just we are allowing---we are not limiting ourselves to fast-forard; feel free to create a merge commit if necessary". So it does imply that the user prefers to merge and does not want to rebase. If you meant what opt_ff can relay, then there are "--no-ff" and "--ff-only" to consider: - "--no-ff" says "we do not allow fast-forward; when the other side is pure descendant of ours, create a merge commit to make them the second parent, so that our side of the history stays to be the first-parent chain that merged them as a side topic." It may not say what should happen when the history does not fast-forward, and it _is_ possible to argue, for the sake of argument, that it asks to rebase if not fast-forward (so that their history becomes the primary and we build on top of them) while asking to merge if fast-forward (so that our history stays the primary and we absorb their work as a side branch), but that is a behavior that does not make much sense. It is much easier to reason about if we accept that the user who says "--no-ff" expects a merge to happen, not a rebase. - "--ff-only" says "when their history is pure descendant of ours, just fast-forward our branch to match their history, and otherwise fail." This one does not have to imply either merge or rebase, as both would give us identical result (i.e. merge would fast-forward and rebase would replay *no* work of our own on top of theirs. Either case, the result is that our branch tip now points at the tip of their history). The topic under discussion is based on the "we do not have to give advice between merge and rebase if the history fast-forwards", and anybody in support of the topic would be in agreement with this case. In any case, I think what we have in 'seen' already is a good stopping point for this cycle. We are not erroring out any new case and simply not showing an advice in a situation that it would not apply---the question "does --ff imply merge?" does not have to be answered in order to evaluate the 5-patch series we have.
