Re: [PATCH RFC] rebase: respect --ff-only option

Junio C Hamano [off-list ref] writes:

Phillip Wood [off-list ref] writes:

quoted

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.