Re: When are you going to stop ignoring pull.mode?

> On 7/16/21 9:14 PM, Felipe Contreras wrote:
> > Elijah Newren wrote:
> >> It may be a worthy goal, but I cannot implement correct behavior if I
> >> cannot determine what correct behavior is.
> >>
> >> You've only specified how to handle a subset of the valid combinations
> >> in each of your emails, and from those individually or even
> >> collectively I cannot deduce rules for handling the others.  Reading
> >> the dozen+ recent messages in the various recent threads, I think I've
> >> figured out your opinion in all but two cases, but I have no idea your
> >> intent on those two (I would have thought --rebase override there too,
> >> but you excluded that), and I'm rather uncertain I've correctly
> >> understood you for the other ones (I really hope gmail doesn't
> >> whitespace damage the following table):
> >>
> >>     pull.ff  pull.rebase  commandline            action
> >>       *          *        --ff-only --rebase     fast-forward only[1]
> >>       *          *        --rebase --no-ff       rebase[1]
> >>       *          *        --rebase --ff          rebase[1]
> >>       *          *        --ff-only --no-rebase  fast-forward only
> >>       *          *        --no-rebase --no-ff    merge --no-ff
> >>       *          *        --no-rebase --ff       merge --ff
> >>
> >>      <unset>     *        --no-rebase            merge --ff
> >>      only        *        --no-rebase            merge --ff[2]
> >>      false       *        --no-rebase            merge --no-ff
> >>      true        *        --no-rebase            merge --ff
> >>
> >>      <unset>     *        --rebase               rebase
> >>      only        *        --rebase               rebase[2]
> >>      false       *        --rebase               ?[2]
> >>      true        *        --rebase               ?[2]
> >>
> >>       *          *        --ff-only              fast-forward only[1]
> >>
> >>       *       <unset>     --no-ff                merge --no-ff
> >>       *        false      --no-ff                merge --no-ff
> >>       *       !false      --no-ff                rebase (ignore --no-ff)[2][3]
> >>
> >>       *       <unset>     --ff                   merge --ff
> >>       *        false      --ff                   merge --ff
> >>       *       !false      --ff                   rebase (ignore --ff)[2][3]
> 
> What about
> 
>           *       !false      --ff-only              ???
> 
> I think these are conflicting options, see [ ] (the ref without a 
> number). This feels like saying oh, I want to rebase, but I want to 
> fast-forward. What should happen with my local changes then? Could one 
> argue that this should lead to the local changes being rebased on top of 
> the remote?