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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 12, 2021, 19:55 UTC
Message-ID: <xmqq8s2b489p.fsf@gitster.g>
In-Reply-To: <CAMMLpeSBgURtX+MKbABKdmFuuoTA-Dw3h8uONwNeiP5aqcnfpA@mail.gmail.com>

Alex Henrie <alexhenrie24@gmail.com> 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.