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

Junio C Hamano wrote:

Alex Henrie [off-list ref] writes:

quoted

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?

Correct. But the documentation says absolutly nothing about
`--ff-only --rebase`.

quoted

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.

Correct again. But currently the only way a fast-forward is possible is
by doing `git merge --ff-only`, which is a merge done in a fast-forward
way.

If we add my proposed `git fast-forward` [1], then the documentation
could be updated to say that --ff-only does a `git fast-forward`, and
thus there's no need for `git merge` (or `git rebase`).

[1] https://lore.kernel.org/git/20210705123209.1808663-4-felipe.contreras@gmail.com/ (local)

-- 
Felipe Contreras