Junio C Hamano <gitster@xxxxxxxxx> writes: > Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > >> Looking at origin/seen:builtin/pull.c we already check if we can >> fast-forward and unconditionally merge in that case irrespective of >> any '--rebase' option or pull.rebase config. It should be simple for >> pull to error out if '--ff-only' is given and we cannot fast-forward. > > Excellent. > > Even though teaching even more special case on the "git pull" side > makes me feel somewhat dirty, but I think it would be a small price > to pay, and the end result would save an useless fork whose sole > purpose is to make the integration step after fetch fail when "pull" > can easily tell, as you said, that it ought to fail, so overall it > would probably be a net win. A tangent after thinking a bit more. I do not think "pull.rebase=interactive" affects the "ff logic" at all. Rebasing integration rebuilds _your_ commits on the current branch on top of the tip of _their_ history, and if their history is a descendant of your history (i.e. the history fast-forwards), by definition, you do not have anything you need to rebuild on top of theirs, whether with the opportunity to make tweaks via "rebase -i" or without. This observation does not change the conclusion at all, but I should have spoken after thinking X-<. Thanks.
