{"thread":{"id":"56119","subject":"When are you going to stop ignoring pull.mode?","startedAt":"2021-07-16T19:14:53Z","lastAt":"2021-07-19T17:37:40Z","messageCount":10,"participants":["Felipe Contreras","Bagas Sanjaya","Matthias Baumgarten","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"430379","messageId":"60f1daa896f69_330208b1@natae.notmuch","threadId":"56119","inReplyTo":null,"subject":"When are you going to stop ignoring pull.mode?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-16T19:14:48Z","receivedAt":"2021-07-16T19:14:53Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Elijah Newren wrote:\n> It may be a worthy goal, but I cannot implement correct behavior if I\n> cannot determine what correct behavior is.\n> \n> You've only specified how to handle a subset of the valid combinations\n> in each of your emails, and from those individually or even\n> collectively I cannot deduce rules for handling the others.  Reading\n> the dozen+ recent messages in the various recent threads, I think I've\n> figured out your opinion in all but two cases, but I have no idea your\n> intent on those two (I would have thought --rebase override there too,\n> but you excluded that), and I'm rather uncertain I've correctly\n> understood you for the other ones (I really hope gmail doesn't\n> whitespace damage the following table):\n> \n>    pull.ff  pull.rebase  commandline            action\n>      *          *        --ff-only --rebase     fast-forward only[1]\n>      *          *        --rebase --no-ff       rebase[1]\n>      *          *        --rebase --ff          rebase[1]\n>      *          *        --ff-only --no-rebase  fast-forward only\n>      *          *        --no-rebase --no-ff    merge --no-ff\n>      *          *        --no-rebase --ff       merge --ff\n> \n>     <unset>     *        --no-rebase            merge --ff\n>     only        *        --no-rebase            merge --ff[2]\n>     false       *        --no-rebase            merge --no-ff\n>     true        *        --no-rebase            merge --ff\n> \n>     <unset>     *        --rebase               rebase\n>     only        *        --rebase               rebase[2]\n>     false       *        --rebase               ?[2]\n>     true        *        --rebase               ?[2]\n> \n>      *          *        --ff-only              fast-forward only[1]\n> \n>      *       <unset>     --no-ff                merge --no-ff\n>      *        false      --no-ff                merge --no-ff\n>      *       !false      --no-ff                rebase (ignore --no-ff)[2][3]\n> \n>      *       <unset>     --ff                   merge --ff\n>      *        false      --ff                   merge --ff\n>      *       !false      --ff                   rebase (ignore --ff)[2][3]\n> \n> [1] https://lore.kernel.org/git/xmqq7dhrtrc2.fsf@gitster.g/\n>     https://lore.kernel.org/git/c62933fb-96b2-99f5-7169-372f486f6e39@aixigo.com/\n> [2] https://lore.kernel.org/git/xmqqpmvn5ukj.fsf@gitster.g/\n> [3] https://lore.kernel.org/git/xmqq8s2b489p.fsf@gitster.g/\n> \n> It appears you, Phillip, and I all had different opinions about\n> correct behavior and in a few cases though the documentation clearly\n> implied what we thought.  So, I'd have to say the documentation is\n> rather unclear as well.  However, even if the above table is filled\n> out, it may be complicated enough that I'm at a bit of a loss about\n> how to update the documentation to explain it short of including the\n> table in the documentation.\n\nYeah, now you are starting to see the problem.\n\nHow many more failed attempts do you need to go through before accepting\nthat the approach you thought was feasible is in fact not feasible?\n\nThe solution is simple and self-documenting:\n\n  pull.mode={fast-forward,merge,rebase}\n\n-- \nFelipe Contreras\n"},{"id":"430406","messageId":"c015e599-0178-cc3d-11be-175dc917f2b9@gmail.com","threadId":"56119","inReplyTo":"60f1daa896f69_330208b1@natae.notmuch","subject":"Re: When are you going to stop ignoring pull.mode?","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2021-07-17T02:14:12Z","receivedAt":"2021-07-17T02:14:28Z","isPatch":false,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"On 17/07/21 02.14, Felipe Contreras wrote:\n> The solution is simple and self-documenting:\n> \n>    pull.mode={fast-forward,merge,rebase}\n> \n\nBut how about config transition from pull.{ff,rebase} to pull.mode?\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"430416","messageId":"c54fa084-75f4-b775-8ac2-6df3c7a36571@aixigo.com","threadId":"56119","inReplyTo":"60f1daa896f69_330208b1@natae.notmuch","subject":"Re: When are you going to stop ignoring pull.mode?","fromName":"Matthias Baumgarten","fromEmail":"matthias.baumgarten@aixigo.com","sentAt":"2021-07-17T10:22:28Z","receivedAt":"2021-07-17T10:22:39Z","isPatch":false,"sender":{"key":"matthias.baumgarten@aixigo.com","avatar":null},"body":"On 7/16/21 9:14 PM, Felipe Contreras wrote:\n> Elijah Newren wrote:\n>> It may be a worthy goal, but I cannot implement correct behavior if I\n>> cannot determine what correct behavior is.\n>>\n>> You've only specified how to handle a subset of the valid combinations\n>> in each of your emails, and from those individually or even\n>> collectively I cannot deduce rules for handling the others.  Reading\n>> the dozen+ recent messages in the various recent threads, I think I've\n>> figured out your opinion in all but two cases, but I have no idea your\n>> intent on those two (I would have thought --rebase override there too,\n>> but you excluded that), and I'm rather uncertain I've correctly\n>> understood you for the other ones (I really hope gmail doesn't\n>> whitespace damage the following table):\n>>\n>>     pull.ff  pull.rebase  commandline            action\n>>       *          *        --ff-only --rebase     fast-forward only[1]\n>>       *          *        --rebase --no-ff       rebase[1]\n>>       *          *        --rebase --ff          rebase[1]\n>>       *          *        --ff-only --no-rebase  fast-forward only\n>>       *          *        --no-rebase --no-ff    merge --no-ff\n>>       *          *        --no-rebase --ff       merge --ff\n>>\n>>      <unset>     *        --no-rebase            merge --ff\n>>      only        *        --no-rebase            merge --ff[2]\n>>      false       *        --no-rebase            merge --no-ff\n>>      true        *        --no-rebase            merge --ff\n>>\n>>      <unset>     *        --rebase               rebase\n>>      only        *        --rebase               rebase[2]\n>>      false       *        --rebase               ?[2]\n>>      true        *        --rebase               ?[2]\n>>\n>>       *          *        --ff-only              fast-forward only[1]\n>>\n>>       *       <unset>     --no-ff                merge --no-ff\n>>       *        false      --no-ff                merge --no-ff\n>>       *       !false      --no-ff                rebase (ignore --no-ff)[2][3]\n>>\n>>       *       <unset>     --ff                   merge --ff\n>>       *        false      --ff                   merge --ff\n>>       *       !false      --ff                   rebase (ignore --ff)[2][3]\n\nWhat about\n\n          *       !false      --ff-only              ???\n\nI think these are conflicting options, see [ ] (the ref without a \nnumber). This feels like saying oh, I want to rebase, but I want to \nfast-forward. What should happen with my local changes then? Could one \nargue that this should lead to the local changes being rebased on top of \nthe remote?\n\n>>\n>> [1] https://lore.kernel.org/git/xmqq7dhrtrc2.fsf@gitster.g/\n>>      https://lore.kernel.org/git/c62933fb-96b2-99f5-7169-372f486f6e39@aixigo.com/\n>> [2] https://lore.kernel.org/git/xmqqpmvn5ukj.fsf@gitster.g/\n>> [3] https://lore.kernel.org/git/xmqq8s2b489p.fsf@gitster.g/\n>>\n>> It appears you, Phillip, and I all had different opinions about\n>> correct behavior and in a few cases though the documentation clearly\n>> implied what we thought.  So, I'd have to say the documentation is\n>> rather unclear as well.  However, even if the above table is filled\n>> out, it may be complicated enough that I'm at a bit of a loss about\n>> how to update the documentation to explain it short of including the\n>> table in the documentation.\n> \n> Yeah, now you are starting to see the problem.\n> \n> How many more failed attempts do you need to go through before accepting\n> that the approach you thought was feasible is in fact not feasible?\n> \n> The solution is simple and self-documenting:\n> \n>    pull.mode={fast-forward,merge,rebase}\n> \n-- \naixigo AG\nKarl-Friedrich-Str. 68, 52072 Aachen, Germany\nphone: +49 (0)241 559709-390, fax: +49 (0)241 559709-99\nemail: matthias.baumgarten@aixigo.com\nweb: https://www.aixigo.com\nDistrict Court Aachen – HRB 8057\nBoard: Christian Friedrich, Tobias Haustein\nChairman of the Supervisory Board: Dr. Roland Schlager\n"},{"id":"430434","messageId":"60f3190eaba81_25f220843@natae.notmuch","threadId":"56119","inReplyTo":"c015e599-0178-cc3d-11be-175dc917f2b9@gmail.com","subject":"Re: When are you going to stop ignoring pull.mode?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-17T17:53:18Z","receivedAt":"2021-07-17T17:53:22Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Bagas Sanjaya wrote:\n> On 17/07/21 02.14, Felipe Contreras wrote:\n> > The solution is simple and self-documenting:\n> > \n> >    pull.mode={fast-forward,merge,rebase}\n> > \n> \n> But how about config transition from pull.{ff,rebase} to pull.mode?\n\nI have already discussed how the transition would look like, and it's\npretty straightforward [1].\n\nAdditionally I already implemented the patch that does the mapping [2].\n\n[1] https://lore.kernel.org/git/5fd8b1d5d4d7c_190cd7208b@natae.notmuch/\n[2] https://lore.kernel.org/git/20210705123209.1808663-27-felipe.contreras@gmail.com/\n\n-- \nFelipe Contreras\n"},{"id":"430435","messageId":"60f31a0ddf7c_25f2208a5@natae.notmuch","threadId":"56119","inReplyTo":"c54fa084-75f4-b775-8ac2-6df3c7a36571@aixigo.com","subject":"Re: When are you going to stop ignoring pull.mode?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-17T17:57:33Z","receivedAt":"2021-07-17T17:57:36Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Matthias Baumgarten wrote:\n> On 7/16/21 9:14 PM, Felipe Contreras wrote:\n> > Elijah Newren wrote:\n> >> It may be a worthy goal, but I cannot implement correct behavior if I\n> >> cannot determine what correct behavior is.\n> >>\n> >> You've only specified how to handle a subset of the valid combinations\n> >> in each of your emails, and from those individually or even\n> >> collectively I cannot deduce rules for handling the others.  Reading\n> >> the dozen+ recent messages in the various recent threads, I think I've\n> >> figured out your opinion in all but two cases, but I have no idea your\n> >> intent on those two (I would have thought --rebase override there too,\n> >> but you excluded that), and I'm rather uncertain I've correctly\n> >> understood you for the other ones (I really hope gmail doesn't\n> >> whitespace damage the following table):\n> >>\n> >>     pull.ff  pull.rebase  commandline            action\n> >>       *          *        --ff-only --rebase     fast-forward only[1]\n> >>       *          *        --rebase --no-ff       rebase[1]\n> >>       *          *        --rebase --ff          rebase[1]\n> >>       *          *        --ff-only --no-rebase  fast-forward only\n> >>       *          *        --no-rebase --no-ff    merge --no-ff\n> >>       *          *        --no-rebase --ff       merge --ff\n> >>\n> >>      <unset>     *        --no-rebase            merge --ff\n> >>      only        *        --no-rebase            merge --ff[2]\n> >>      false       *        --no-rebase            merge --no-ff\n> >>      true        *        --no-rebase            merge --ff\n> >>\n> >>      <unset>     *        --rebase               rebase\n> >>      only        *        --rebase               rebase[2]\n> >>      false       *        --rebase               ?[2]\n> >>      true        *        --rebase               ?[2]\n> >>\n> >>       *          *        --ff-only              fast-forward only[1]\n> >>\n> >>       *       <unset>     --no-ff                merge --no-ff\n> >>       *        false      --no-ff                merge --no-ff\n> >>       *       !false      --no-ff                rebase (ignore --no-ff)[2][3]\n> >>\n> >>       *       <unset>     --ff                   merge --ff\n> >>       *        false      --ff                   merge --ff\n> >>       *       !false      --ff                   rebase (ignore --ff)[2][3]\n> \n> What about\n> \n>           *       !false      --ff-only              ???\n> \n> I think these are conflicting options, see [ ] (the ref without a \n> number). This feels like saying oh, I want to rebase, but I want to \n> fast-forward. What should happen with my local changes then? Could one \n> argue that this should lead to the local changes being rebased on top of \n> the remote?\n\nAccording to the above it would be a fast-forward only, because:\n\n      *          *        --ff-only              fast-forward only\n\nSo the pull would abort f you have local changes.\n\n-- \nFelipe Contreras\n"},{"id":"430445","messageId":"xmqqwnpooctj.fsf@gitster.g","threadId":"56119","inReplyTo":"c54fa084-75f4-b775-8ac2-6df3c7a36571@aixigo.com","subject":"Re: When are you going to stop ignoring pull.mode?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-17T21:22:32Z","receivedAt":"2021-07-17T21:22:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthias Baumgarten <matthias.baumgarten@aixigo.com> writes:\n\n>>>     pull.ff  pull.rebase  commandline            action\n>>> ...\n>>>       *          *        --ff-only              fast-forward only[1]\n>>> ...\n> What about\n>\n>          *       !false      --ff-only              ???\n\nThis is covered by an earlier entry (\"*\" stands for \"any value\"), I\nthink; it should fast-forward or fail.  The reasoning goes like\nthis:\n\nThe user configures pull.rebase to some kind of rebase; it could be\njust true (the traditional flattening rebase), or the one that\npreserves the shape of the history, or even the interactive one.\nWith the configuration, what the user declares is: \n\n    I may have my own development on top of the result of my last\n    integration with the upstream I did when I ran \"git pull\" the\n    last time, and when the upstream has more commits, the way I\n    want my local work to integrate with their work is to replay my\n    work on top of theirs (as opposed to \"merging their work into my\n    history\").\n\nBut by passing \"--ff-only\" from the command line, the user tells us\nthis:\n\n    This time only, I want fast-forward update and nothing else.  I\n    do not remember doing any of my own development on top of their\n    history, and I expect that this update from the upstream would\n    fast-forward.  If that is not the case, please error out, as I\n    need to inspect the situation further and I do not want to see\n    conflicts in unexpected commits I thought I did not have.\n\nSo the \"action\" would be\n\n - If their history is a descendant of ours, that means that on top\n   of their history previously observed by us, we haven't added any\n   development of our own.  We just move to the tip of their history\n   and we are done.\n\n   This is not so surprising anyway.  If we are doing any kind of\n   rebasing, what happens is to start from the tip of their history\n   and then commits from our own development are replayed on top of\n   that.  When their history is a descendant of ours, we end up\n   doing just fast-forward, as there is nothing to replay on top.\n\n - Otherwise, because the user expects the command to fail if their\n   history is not a descendant of ours, we fail.\n\nAnd \"fast-forward only\" in Elijah's table is a concise way to say\nthat.\n\nI concentrated on \"if the configuration is set to do some kind of\nrebase\" case, as that was your question, but the above reasoning\napplies equally to the case where pull.rebase is not specified or\nset to false, i.e. the user tells us to merge.\n"},{"id":"430450","messageId":"60f352bce4d53_554620882@natae.notmuch","threadId":"56119","inReplyTo":"xmqqwnpooctj.fsf@gitster.g","subject":"Re: When are you going to stop ignoring pull.mode?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-17T21:59:24Z","receivedAt":"2021-07-17T21:59:46Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Matthias Baumgarten <matthias.baumgarten@aixigo.com> writes:\n> \n> >>>     pull.ff  pull.rebase  commandline            action\n> >>> ...\n> >>>       *          *        --ff-only              fast-forward only[1]\n> >>> ...\n> > What about\n> >\n> >          *       !false      --ff-only              ???\n> \n> This is covered by an earlier entry (\"*\" stands for \"any value\"), I\n> think; it should fast-forward or fail.  The reasoning goes like\n> this:\n> \n> The user configures pull.rebase to some kind of rebase; it could be\n> just true (the traditional flattening rebase), or the one that\n> preserves the shape of the history, or even the interactive one.\n> With the configuration, what the user declares is: \n> \n>     I may have my own development on top of the result of my last\n>     integration with the upstream I did when I ran \"git pull\" the\n>     last time, and when the upstream has more commits, the way I\n>     want my local work to integrate with their work is to replay my\n>     work on top of theirs (as opposed to \"merging their work into my\n>     history\").\n> \n> But by passing \"--ff-only\" from the command line, the user tells us\n> this:\n> \n>     This time only, I want fast-forward update and nothing else.  I\n>     do not remember doing any of my own development on top of their\n>     history, and I expect that this update from the upstream would\n>     fast-forward.  If that is not the case, please error out, as I\n>     need to inspect the situation further and I do not want to see\n>     conflicts in unexpected commits I thought I did not have.\n\nNo, this is what you think the user would be telling us, but that's not\nwhat the user is *actually* telling us right now.\n\n  git -c pull.ff=only pull --rebase\n\nWhat the user is actually telling us right now is that while he normally\nwould expect a fast-forward, in this case he would like a rebase.\n\nToday this is the equivalent of:\n\n  git -c pull.rebase=true pull --ff-only\n\nIf you change this interpretation, it would break the symmetry between\nconfigurations and command line arguments.\n\n> So the \"action\" would be\n> \n>  - If their history is a descendant of ours, that means that on top\n>    of their history previously observed by us, we haven't added any\n>    development of our own.  We just move to the tip of their history\n>    and we are done.\n> \n>    This is not so surprising anyway.  If we are doing any kind of\n>    rebasing, what happens is to start from the tip of their history\n>    and then commits from our own development are replayed on top of\n>    that.  When their history is a descendant of ours, we end up\n>    doing just fast-forward, as there is nothing to replay on top.\n\nBut --ff-only is not for rebases, the documentation is very clear:\n\n\tSpecifies how a merge is handled when the merged-in history is\n\talready a descendant of the current history.  `--ff` is the\n\tdefault unless merging an annotated (and possibly signed) tag\n\tthat is not stored in its natural place in the `refs/tags/`\n\thierarchy, in which case `--no-ff` is assumed.\n\n  With `--ff-only`, resolve the merge as a fast-forward when possible.\n  When not possible, refuse to merge and exit with a non-zero status.\n\n>  - Otherwise, because the user expects the command to fail if their\n>    history is not a descendant of ours, we fail.\n> \n> And \"fast-forward only\" in Elijah's table is a concise way to say\n> that.\n\nYes, but it's taking us in the wrong direction by ignoring how the users\nactually use --ff-only today, what the documentation actually says,\nbreaking the symmetry of configurations and arguments, and making\neverything less intuitive.\n\n\nOn the other hand if --ff-only was mapped to pull.mode=fast-forward\ninstead, everything is clear:\n\n  git -c pull.mode=fast-forward pull --rebase\n  git -c pull.mode=rebase pull --ff-only\n\nI don't even need to explain what these do.\n\n-- \nFelipe Contreras\n"},{"id":"430504","messageId":"948ef19f-5588-62e9-6fc7-aa6d82f21a1b@aixigo.com","threadId":"56119","inReplyTo":"xmqqwnpooctj.fsf@gitster.g","subject":"Re: When are you going to stop ignoring pull.mode?","fromName":"Matthias Baumgarten","fromEmail":"matthias.baumgarten@aixigo.com","sentAt":"2021-07-19T14:14:14Z","receivedAt":"2021-07-19T14:14:26Z","isPatch":false,"sender":{"key":"matthias.baumgarten@aixigo.com","avatar":null},"body":"On 7/17/21 11:22 PM, Junio C Hamano wrote:\n> Matthias Baumgarten <matthias.baumgarten@aixigo.com> writes:\n> \n>>>>      pull.ff  pull.rebase  commandline            action\n>>>> ...\n>>>>        *          *        --ff-only              fast-forward only[1]\n>>>> ...\n>> What about\n>>\n>>           *       !false      --ff-only              ???\n> \n> This is covered by an earlier entry (\"*\" stands for \"any value\"), I\n> think; it should fast-forward or fail.  The reasoning goes like\n> this:\nAh, I just misunderstood *, nevermind!\n> \n> The user configures pull.rebase to some kind of rebase; it could be\n> just true (the traditional flattening rebase), or the one that\n> preserves the shape of the history, or even the interactive one.\n> With the configuration, what the user declares is:\n> \n>      I may have my own development on top of the result of my last\n>      integration with the upstream I did when I ran \"git pull\" the\n>      last time, and when the upstream has more commits, the way I\n>      want my local work to integrate with their work is to replay my\n>      work on top of theirs (as opposed to \"merging their work into my\n>      history\").\n> \n> But by passing \"--ff-only\" from the command line, the user tells us\n> this:\n> \n>      This time only, I want fast-forward update and nothing else.  I\n>      do not remember doing any of my own development on top of their\n>      history, and I expect that this update from the upstream would\n>      fast-forward.  If that is not the case, please error out, as I\n>      need to inspect the situation further and I do not want to see\n>      conflicts in unexpected commits I thought I did not have.\n> \n> So the \"action\" would be\n> \n>   - If their history is a descendant of ours, that means that on top\n>     of their history previously observed by us, we haven't added any\n>     development of our own.  We just move to the tip of their history\n>     and we are done.\n> \n>     This is not so surprising anyway.  If we are doing any kind of\n>     rebasing, what happens is to start from the tip of their history\n>     and then commits from our own development are replayed on top of\n>     that.  When their history is a descendant of ours, we end up\n>     doing just fast-forward, as there is nothing to replay on top.\n> \n>   - Otherwise, because the user expects the command to fail if their\n>     history is not a descendant of ours, we fail.\n> \n> And \"fast-forward only\" in Elijah's table is a concise way to say\n> that.\n\nAgree.\n> \n> I concentrated on \"if the configuration is set to do some kind of\n> rebase\" case, as that was your question, but the above reasoning\n> applies equally to the case where pull.rebase is not specified or\n> set to false, i.e. the user tells us to merge.\n> \n\nPerfectly valid reasoning.\n\nInitially I came from the situation where I (as maintainer of a \nrepository) proposed to do a `git pull --ff-only <remote-git-url> \n<branch-name>` for the others to integrate the newest changes safely \n(i.e. failing if they had errouneously worked on that branch, which it \nis not intended for). I thought I could reach that safety with the \n`--ff-only` part, but it seems one of the devs had pull.rebase set for \nhim locally and thus managed to bypass my \"safety\". Mr. Elijah Newren \ncalled this a bug, see [1].\n\nAnother way for the others to integrate my changes would be to propose a \n`git reset --hard ...` but that seems very... hard. It would overwrite \nall local changes (only recoverable by the reflog then, and you would \neven need to know that you had local changes in the first place).\n\n[1] \nhttps://lore.kernel.org/git/CABPp-BEHZcfZNL+PG1vmqXGf4Qs3eoULb4NDDgbmOB30HzJu_Q@mail.gmail.com/\n\n-- \naixigo AG\nKarl-Friedrich-Str. 68, 52072 Aachen, Germany\nphone: +49 (0)241 559709-390, fax: +49 (0)241 559709-99\nemail: matthias.baumgarten@aixigo.com\nweb: https://www.aixigo.com\nDistrict Court Aachen – HRB 8057\nBoard: Christian Friedrich, Tobias Haustein\nChairman of the Supervisory Board: Dr. Roland Schlager\n"},{"id":"430513","messageId":"xmqq4kcqnt0i.fsf@gitster.g","threadId":"56119","inReplyTo":"948ef19f-5588-62e9-6fc7-aa6d82f21a1b@aixigo.com","subject":"Re: When are you going to stop ignoring pull.mode?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-19T16:54:53Z","receivedAt":"2021-07-19T17:00:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthias Baumgarten <matthias.baumgarten@aixigo.com> writes:\n\n> Initially I came from the situation where I (as maintainer of a\n> repository) proposed to do a `git pull --ff-only <remote-git-url> \n> <branch-name>` for the others to integrate the newest changes safely\n> (i.e. failing if they had errouneously worked on that branch, which it \n> is not intended for). I thought I could reach that safety with the\n> `--ff-only` part, but it seems one of the devs had pull.rebase set for \n> him locally and thus managed to bypass my \"safety\". Mr. Elijah Newren\n> called this a bug, see [1].\n\nYes, I saw it and I agree with Elijah.\n\nThanks.\n"},{"id":"430520","messageId":"60f5b3143fd26_13f2e220892@natae.notmuch","threadId":"56119","inReplyTo":"948ef19f-5588-62e9-6fc7-aa6d82f21a1b@aixigo.com","subject":"Re: When are you going to stop ignoring pull.mode?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-19T17:15:00Z","receivedAt":"2021-07-19T17:37:40Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Matthias Baumgarten wrote:\n> On 7/17/21 11:22 PM, Junio C Hamano wrote:\n\n> > I concentrated on \"if the configuration is set to do some kind of\n> > rebase\" case, as that was your question, but the above reasoning\n> > applies equally to the case where pull.rebase is not specified or\n> > set to false, i.e. the user tells us to merge.\n> > \n> \n> Perfectly valid reasoning.\n> \n> Initially I came from the situation where I (as maintainer of a \n> repository) proposed to do a `git pull --ff-only <remote-git-url> \n> <branch-name>` for the others to integrate the newest changes safely \n> (i.e. failing if they had errouneously worked on that branch, which it \n> is not intended for). I thought I could reach that safety with the \n> `--ff-only` part, but it seems one of the devs had pull.rebase set for \n> him locally and thus managed to bypass my \"safety\". Mr. Elijah Newren \n> called this a bug, see [1].\n\nIt's not a bug. It could be made a bug if the semantics of --ff-only\nwere changed to something that overrides pull.rebase, but that something\ndoesn't exist yet:\n\n  pull.mode=fast-forward\n\nRight now it can't be done.\n\n-- \nFelipe Contreras\n"}]}