Junio C Hamano wrote: > 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. But Elijah's statement is correct. `git pull --no-ff --rebase` is undocumented. Period. -- Felipe Contreras
