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

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