Re: [PATCH 3/5] pull: handle conflicting rebase/merge options via last option wins

> >  pull.rebase::
> >  	When true, rebase branches on top of the fetched branch, instead
> >  	of merging the default branch from the default remote when "git
> >  	pull" is run. See "branch.<name>.rebase" for setting this on a
> > -	per-branch basis.
> > +	per-branch basis.  Incompatible with pull.ff.
> 
> Likewise.
> 
> I think it technically is OK to say "only ff update is allowed" or
> "ff update is allowed when able" while saying pull.rebase=yes.  
> 
>  - For those who say ff=only, the actual value of pull.rebase would
>    not matter (i.e. the integration immediately finishes by updating
>    to what was obtained from the upstream because there is no new
>    development on our own on top of theirs to either replay or
>    merge).
> 
>  - For those who merely allow ff, an update may fast-forward even
>    when pull.rebase is set to true (or any non-false value), while
>    we'll replay our own development on top of theirs when their
>    history is not descendent of ours.
> 
> So I do not see need to declare these combinations "incompatible".
> But perhaps I am missing some subtle cases?