When are you going to stop ignoring pull.mode?

> 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]
> 
> [1] https://lore.kernel.org/git/xmqq7dhrtrc2.fsf@gitster.g/
>     https://lore.kernel.org/git/c62933fb-96b2-99f5-7169-372f486f6e39@aixigo.com/
> [2] https://lore.kernel.org/git/xmqqpmvn5ukj.fsf@gitster.g/
> [3] https://lore.kernel.org/git/xmqq8s2b489p.fsf@gitster.g/
> 
> It appears you, Phillip, and I all had different opinions about
> correct behavior and in a few cases though the documentation clearly
> implied what we thought.  So, I'd have to say the documentation is
> rather unclear as well.  However, even if the above table is filled
> out, it may be complicated enough that I'm at a bit of a loss about
> how to update the documentation to explain it short of including the
> table in the documentation.

> On 17/07/21 02.14, Felipe Contreras wrote:
> > The solution is simple and self-documenting:
> > 
> >    pull.mode={fast-forward,merge,rebase}
> > 
> 
> But how about config transition from pull.{ff,rebase} to pull.mode?

> 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]

>>
>> [1] https://lore.kernel.org/git/xmqq7dhrtrc2.fsf@gitster.g/
>>      https://lore.kernel.org/git/c62933fb-96b2-99f5-7169-372f486f6e39@aixigo.com/
>> [2] https://lore.kernel.org/git/xmqqpmvn5ukj.fsf@gitster.g/
>> [3] https://lore.kernel.org/git/xmqq8s2b489p.fsf@gitster.g/
>>
>> It appears you, Phillip, and I all had different opinions about
>> correct behavior and in a few cases though the documentation clearly
>> implied what we thought.  So, I'd have to say the documentation is
>> rather unclear as well.  However, even if the above table is filled
>> out, it may be complicated enough that I'm at a bit of a loss about
>> how to update the documentation to explain it short of including the
>> table in the documentation.
> 
> Yeah, now you are starting to see the problem.
> 
> How many more failed attempts do you need to go through before accepting
> that the approach you thought was feasible is in fact not feasible?
> 
> The solution is simple and self-documenting:
> 
>    pull.mode={fast-forward,merge,rebase}
> 

> 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?

>>>     pull.ff  pull.rebase  commandline            action
>>> ...
>>>       *          *        --ff-only              fast-forward only[1]
>>> ...
> What about
>
>          *       !false      --ff-only              ???

> Matthias Baumgarten <matthias.baumgarten@aixigo.com> writes:
> 
> >>>     pull.ff  pull.rebase  commandline            action
> >>> ...
> >>>       *          *        --ff-only              fast-forward only[1]
> >>> ...
> > What about
> >
> >          *       !false      --ff-only              ???
> 
> This is covered by an earlier entry ("*" stands for "any value"), I
> think; it should fast-forward or fail.  The reasoning goes like
> this:
> 
> The user configures pull.rebase to some kind of rebase; it could be
> just true (the traditional flattening rebase), or the one that
> preserves the shape of the history, or even the interactive one.
> With the configuration, what the user declares is: 
> 
>     I may have my own development on top of the result of my last
>     integration with the upstream I did when I ran "git pull" the
>     last time, and when the upstream has more commits, the way I
>     want my local work to integrate with their work is to replay my
>     work on top of theirs (as opposed to "merging their work into my
>     history").
> 
> But by passing "--ff-only" from the command line, the user tells us
> this:
> 
>     This time only, I want fast-forward update and nothing else.  I
>     do not remember doing any of my own development on top of their
>     history, and I expect that this update from the upstream would
>     fast-forward.  If that is not the case, please error out, as I
>     need to inspect the situation further and I do not want to see
>     conflicts in unexpected commits I thought I did not have.

> So the "action" would be
> 
>  - If their history is a descendant of ours, that means that on top
>    of their history previously observed by us, we haven't added any
>    development of our own.  We just move to the tip of their history
>    and we are done.
> 
>    This is not so surprising anyway.  If we are doing any kind of
>    rebasing, what happens is to start from the tip of their history
>    and then commits from our own development are replayed on top of
>    that.  When their history is a descendant of ours, we end up
>    doing just fast-forward, as there is nothing to replay on top.

>  - Otherwise, because the user expects the command to fail if their
>    history is not a descendant of ours, we fail.
> 
> And "fast-forward only" in Elijah's table is a concise way to say
> that.

> Matthias Baumgarten <matthias.baumgarten@aixigo.com> writes:
> 
>>>>      pull.ff  pull.rebase  commandline            action
>>>> ...
>>>>        *          *        --ff-only              fast-forward only[1]
>>>> ...
>> What about
>>
>>           *       !false      --ff-only              ???
> 
> This is covered by an earlier entry ("*" stands for "any value"), I
> think; it should fast-forward or fail.  The reasoning goes like
> this:

> 
> The user configures pull.rebase to some kind of rebase; it could be
> just true (the traditional flattening rebase), or the one that
> preserves the shape of the history, or even the interactive one.
> With the configuration, what the user declares is:
> 
>      I may have my own development on top of the result of my last
>      integration with the upstream I did when I ran "git pull" the
>      last time, and when the upstream has more commits, the way I
>      want my local work to integrate with their work is to replay my
>      work on top of theirs (as opposed to "merging their work into my
>      history").
> 
> But by passing "--ff-only" from the command line, the user tells us
> this:
> 
>      This time only, I want fast-forward update and nothing else.  I
>      do not remember doing any of my own development on top of their
>      history, and I expect that this update from the upstream would
>      fast-forward.  If that is not the case, please error out, as I
>      need to inspect the situation further and I do not want to see
>      conflicts in unexpected commits I thought I did not have.
> 
> So the "action" would be
> 
>   - If their history is a descendant of ours, that means that on top
>     of their history previously observed by us, we haven't added any
>     development of our own.  We just move to the tip of their history
>     and we are done.
> 
>     This is not so surprising anyway.  If we are doing any kind of
>     rebasing, what happens is to start from the tip of their history
>     and then commits from our own development are replayed on top of
>     that.  When their history is a descendant of ours, we end up
>     doing just fast-forward, as there is nothing to replay on top.
> 
>   - Otherwise, because the user expects the command to fail if their
>     history is not a descendant of ours, we fail.
> 
> And "fast-forward only" in Elijah's table is a concise way to say
> that.

> 
> I concentrated on "if the configuration is set to do some kind of
> rebase" case, as that was your question, but the above reasoning
> applies equally to the case where pull.rebase is not specified or
> set to false, i.e. the user tells us to merge.
> 

> Initially I came from the situation where I (as maintainer of a
> repository) proposed to do a `git pull --ff-only <remote-git-url> 
> <branch-name>` for the others to integrate the newest changes safely
> (i.e. failing if they had errouneously worked on that branch, which it 
> is not intended for). I thought I could reach that safety with the
> `--ff-only` part, but it seems one of the devs had pull.rebase set for 
> him locally and thus managed to bypass my "safety". Mr. Elijah Newren
> called this a bug, see [1].

> > I concentrated on "if the configuration is set to do some kind of
> > rebase" case, as that was your question, but the above reasoning
> > applies equally to the case where pull.rebase is not specified or
> > set to false, i.e. the user tells us to merge.
> > 
> 
> Perfectly valid reasoning.
> 
> Initially I came from the situation where I (as maintainer of a 
> repository) proposed to do a `git pull --ff-only <remote-git-url> 
> <branch-name>` for the others to integrate the newest changes safely 
> (i.e. failing if they had errouneously worked on that branch, which it 
> is not intended for). I thought I could reach that safety with the 
> `--ff-only` part, but it seems one of the devs had pull.rebase set for 
> him locally and thus managed to bypass my "safety". Mr. Elijah Newren 
> called this a bug, see [1].