Re: [PATCH] pull: abort if --ff-only is given and fast-forwarding is impossible

Alex Henrie [off-list ref] writes:

Sorry, I misspoke. I was thinking of the case where fast-forwarding is
impossible.

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?

If fast-forwarding is possible, --ff-only already effectively
implies --no-rebase, and we might want to make that explicit in
the documentation.

When we fast-forward (i.e. their history is descendant from ours,
and the user did not give --no-ff), it does not matter if it is done
using the merge backend, the rebase backend, or by the "git pull"
wrapper. The end user does not care.  The end result is that the tip
of the branch now points at the tip of the history we pulled from
the other side and that is all what matters.

So, from that point of view, I do not think we want to say rebase or
merge or anything else for such a case in the documentation.

THanks.