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

Matthias Baumgarten <matthias.baumgarten@aixigo.com> writes:

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.