Elijah Newren <newren@xxxxxxxxx> writes: >> When we cannot fast-forward (i.e. we have our own development that >> is not in the tip of their history), >> >> --ff-only would cause the operation fail >> --ff would become no-op (as it merely allows fast-forwarding) >> --no-ff would become no-op (as it merely forbids fast-forwarding) >> >> and the latter two case, we'd either merge or rebase (with possibly >> specified mode like --preserve-merges). I thought the current >> documentation is already fairly clear on this point? > > git pull's --no-ff is documented to "create a merge commit in all > cases", and thus as worded, seems incompatible with rebasing to me. It smells like a "too literally to be useful" interpretation of a pice of documentation that has no relevance to "pull --rebase" to me, though. It comes from merge-options.txt and would not be relevant to "git pull --rebase" to begin with.
