{"thread":{"id":"54693","subject":"Pick the right default and stop warn on `git pull`","startedAt":"2020-11-23T15:13:26Z","lastAt":"2020-11-26T01:02:44Z","messageCount":29,"participants":["Vít Ondruch","Alex Henrie","Junio C Hamano","Theodore Y. Ts'o","Felipe Contreras","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"410529","messageId":"742df4c2-2bc5-8a4b-8de1-cd5e48718398@redhat.com","threadId":"54693","inReplyTo":null,"subject":"Pick the right default and stop warn on `git pull`","fromName":"Vít Ondruch","fromEmail":"vondruch@redhat.com","sentAt":"2020-11-23T15:13:08Z","receivedAt":"2020-11-23T15:13:26Z","isPatch":false,"sender":{"key":"vondruch@redhat.com","avatar":"https://gravatar.com/avatar/a970a28d3861748910124659b43dbb020284a26b591f29cd27c126284e44bfa3?d=mp&s=160"},"body":"Hi,\n\nWhile I understand that the merge after `git pull` is probably not the \nbest strategy (as explained in [1]), asking people to change their \nconfiguration to choose their default strategy with every `git pull` is \nnot any better. Please select any strategy considered more appropriate \nand stop warning me. I know I could change my configuration, but I'll \nchange it just if I want to differ from defaults. I don't need to be \ntold that I am using wrong default. I'd like to keep my trust in Git \nupstream, but this is was not trustworthy decision IMO.\n\nBTW, I was motivated to open this discussion by this [2] Fedora ticket.\n\n\nVít\n\n\n\n[1] https://github.com/git/git/commit/d18c950a69\n\n[2] https://bugzilla.redhat.com/show_bug.cgi?id=1900441\n\n"},{"id":"410543","messageId":"CAMMLpeRLsE=zNDjCRKmEMFxJBYcnTOdDGxEL9cZuVhuDMF=sLg@mail.gmail.com","threadId":"54693","inReplyTo":"742df4c2-2bc5-8a4b-8de1-cd5e48718398@redhat.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2020-11-23T17:59:13Z","receivedAt":"2020-11-23T18:00:03Z","isPatch":false,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Mon, Nov 23, 2020 at 8:14 AM Vít Ondruch wrote:\n>\n> Hi,\n>\n> While I understand that the merge after `git pull` is probably not the\n> best strategy (as explained in [1]), asking people to change their\n> configuration to choose their default strategy with every `git pull` is\n> not any better. Please select any strategy considered more appropriate\n> and stop warning me. I know I could change my configuration, but I'll\n> change it just if I want to differ from defaults. I don't need to be\n> told that I am using wrong default. I'd like to keep my trust in Git\n> upstream, but this is was not trustworthy decision IMO.\n>\n> BTW, I was motivated to open this discussion by this [2] Fedora ticket.\n>\n>\n> Vít\n>\n>\n>\n> [1] https://github.com/git/git/commit/d18c950a69\n>\n> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1900441\n\nHi Vit, as the message explains, you can use `git config --global\npull.rebase false` to permanently silence the warning for all of your\nrepositories. The idea is that in a future version of Git, users will\nnot be allowed to pull at all without specifying a reconciliation\nstrategy. This will prevent users (novices in particular) from\naccidentally creating messes by merging branches that should have been\nrebased instead.\n\nPersonally, I would rather have pull.rebase be true by default (and\nI'm sure many others would like that too), but there are so many users\nwho really do want to merge that it's not reasonable to make rebasing\nthe default. The most reasonable solution is to ask the user to be\nexplicit about what they want and not make assumptions.\n\n-Alex\n"},{"id":"410550","messageId":"xmqqh7pfopki.fsf@gitster.c.googlers.com","threadId":"54693","inReplyTo":"742df4c2-2bc5-8a4b-8de1-cd5e48718398@redhat.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-11-23T19:12:13Z","receivedAt":"2020-11-23T19:12:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Vít Ondruch writes:\n\n> While I understand that the merge after `git pull` is probably not the\n> best strategy (as explained in [1]), asking people to change their \n> configuration to choose their default strategy with every `git pull`\n> is not any better.\n\nThere is no clear \"default that would suit everybody\". There are\nmany people for whom 'rebase' is totally a wrong thing in their\n'pull', and there are many people for whom 'merge' is totally a\nwrong thing in their 'pull'. Worse, because a user does not\nnecessarily play the same role in multiple projects, even the same\nhuman user may want to use 'rebase' while working on some projects\nwhile 'merge' is preferred on other projects.\n\nAnd the userbase of Git is large enough that it is no longer a\nviable approach to say \"which group has more people? pick the one\nthat is better to them\" unless we are dealing with a _new_ feature.\nEven 1% minority of the userbase is still a large number in absolute\nterms.\n\nThat is why pull.rebase=(yes|no) exists to serve people with either\nworkflow to record preference just once for the repository with \"git\nconfig\" and \"git pull\" would stop asking in the repository.\n\nWhen they always prefer one way, they can even run \"git config\n--global\" just once and the setting applies to all of their\nrepositories, stopping \"git pull\" from asking in any repository.\n\n"},{"id":"410551","messageId":"20201123191355.GA132317@mit.edu","threadId":"54693","inReplyTo":"CAMMLpeRLsE=zNDjCRKmEMFxJBYcnTOdDGxEL9cZuVhuDMF=sLg@mail.gmail.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Theodore Y. Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2020-11-23T19:13:55Z","receivedAt":"2020-11-23T19:14:02Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Nov 23, 2020 at 10:59:13AM -0700, Alex Henrie wrote:\n> \n> Hi Vit, as the message explains, you can use `git config --global\n> pull.rebase false` to permanently silence the warning for all of your\n> repositories. The idea is that in a future version of Git, users will\n> not be allowed to pull at all without specifying a reconciliation\n> strategy. This will prevent users (novices in particular) from\n> accidentally creating messes by merging branches that should have been\n> rebased instead.\n> \n> Personally, I would rather have pull.rebase be true by default (and\n> I'm sure many others would like that too), but there are so many users\n> who really do want to merge that it's not reasonable to make rebasing\n> the default. The most reasonable solution is to ask the user to be\n> explicit about what they want and not make assumptions.\n\nIt's really going to depend on your workflow. If your repository is\nused as a building point by other repositories, and you pull from the\nupstream repo, rebasing may cause a massive headache for your\ndownstream \"sub-maintainers\" (assuming that you are a subsystem\nmaintainer).\n\nIf your repository is effectively a leaf repo, then rebasing may be\nharmless, although there are still who don't like rebasing because it\ninvalidates your previous testing. My personal preference is to do a\ngit fetch, followed by a git merge --ff-only, and if that errors out,\nthen I know I need to take a bit more care before deciding what to do\nnext.\n\nBut everyone's workflow varies, which is why creating a default is\ngoing to controversial no matter what the default might be.\n\nCheers,\n\n\t\t\t\t\t- Ted\n"},{"id":"410555","messageId":"CAMP44s2H6ubW47RCEs4B4qafpU8Z4Z9Ue3BaAMB-T_pEcxkXig@mail.gmail.com","threadId":"54693","inReplyTo":"xmqqh7pfopki.fsf@gitster.c.googlers.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-23T19:37:33Z","receivedAt":"2020-11-23T19:38:07Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 23, 2020 at 1:15 PM Junio C Hamano wrote:\n> Vít Ondruch writes:\n\n> > While I understand that the merge after `git pull` is probably not the\n> > best strategy (as explained in [1]), asking people to change their\n> > configuration to choose their default strategy with every `git pull`\n> > is not any better.\n>\n> There is no clear \"default that would suit everybody\".\n\nThis is a false dichotomy.\n\nYes, there's no default that would suit everybody, but there is a\nbetter default than the current one:\n\nfast-forward-only:\n\nhttps://lore.kernel.org/git/1398988808-29678-1-git-send-email-felipe.contreras@gmail.com/\n\n-- \nFelipe Contreras\n"},{"id":"410557","messageId":"CAMP44s3cKVxKa0gOPfi3XRKbGbV=DweFE5pL0HM+v0kECFyPWA@mail.gmail.com","threadId":"54693","inReplyTo":"20201123191355.GA132317@mit.edu","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-23T19:40:38Z","receivedAt":"2020-11-23T19:40:52Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 23, 2020 at 1:17 PM Theodore Y. Ts'o wrote:\n\n> If your repository is effectively a leaf repo, then rebasing may be\n> harmless, although there are still who don't like rebasing because it\n> invalidates your previous testing. My personal preference is to do a\n> git fetch, followed by a git merge --ff-only, and if that errors out,\n> then I know I need to take a bit more care before deciding what to do\n> next.\n\nWhich is why I suggested to make fast-forward-only the default:\n\nhttps://lore.kernel.org/git/1398988808-29678-1-git-send-email-felipe.contreras@gmail.com/\n\nIn what case would that default not be what most people want?\n\n-- \nFelipe Contreras\n"},{"id":"410559","messageId":"CAMP44s2rhOXfqmyd-rUUmzjsbqq9juf1HNsd32aO-Qcd-m0QNw@mail.gmail.com","threadId":"54693","inReplyTo":"742df4c2-2bc5-8a4b-8de1-cd5e48718398@redhat.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-23T19:43:31Z","receivedAt":"2020-11-23T19:43:45Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 23, 2020 at 9:17 AM Vít Ondruch wrote:\n\n> While I understand that the merge after `git pull` is probably not the\n> best strategy (as explained in [1]), asking people to change their\n> configuration to choose their default strategy with every `git pull` is\n> not any better. Please select any strategy considered more appropriate\n> and stop warning me. I know I could change my configuration, but I'll\n> change it just if I want to differ from defaults. I don't need to be\n> told that I am using wrong default. I'd like to keep my trust in Git\n> upstream, but this is was not trustworthy decision IMO.\n\nIndeed.\n\nThis is why I sent patches to change the \"git pull\" default to merge\nthe remote branch, but only if it's a fast-forward. If it's not, then\nthe user would have to either merge, or rebase.\n\nhttps://lore.kernel.org/git/1398988808-29678-1-git-send-email-felipe.contreras@gmail.com/\n\nThis is the best sensible default.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"410564","messageId":"20201123202003.GB132317@mit.edu","threadId":"54693","inReplyTo":"CAMP44s3cKVxKa0gOPfi3XRKbGbV=DweFE5pL0HM+v0kECFyPWA@mail.gmail.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Theodore Y. Ts'o","fromEmail":"tytso@mit.edu","sentAt":"2020-11-23T20:20:03Z","receivedAt":"2020-11-23T20:20:11Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Nov 23, 2020 at 01:40:38PM -0600, Felipe Contreras wrote:\n> On Mon, Nov 23, 2020 at 1:17 PM Theodore Y. Ts'o wrote:\n> \n> > If your repository is effectively a leaf repo, then rebasing may be\n> > harmless, although there are still who don't like rebasing because it\n> > invalidates your previous testing. My personal preference is to do a\n> > git fetch, followed by a git merge --ff-only, and if that errors out,\n> > then I know I need to take a bit more care before deciding what to do\n> > next.\n> \n> Which is why I suggested to make fast-forward-only the default:\n> \n> https://lore.kernel.org/git/1398988808-29678-1-git-send-email-felipe.contreras@gmail.com/\n> \n> In what case would that default not be what most people want?\n\nWell, it *was* the default, previously, IIRC. The problem is that for\n\"simple\" use cases, using rebases for git-pull is \"simpler\". Well,\nit's simpler until it does something super-surprising when the project\nbecomes more complex, but if the goal is to have a more gentle\nlearning curve for newbies, especially for small projects --- which\nare the vast majority of projectds, on, say github and sourceforge ---\nthe case can be made.\n\nSo intead of having a huge discussion which is going to be very hard\nto come to converge (much like the \"main\" vs \"master\" question),\nrequiring people to set their own global default or per-repo default\nis a pretty good compromise.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"410565","messageId":"CAMP44s27oEjScrJjeDVoNcWcvRsn173L_Kx+TOPfchOwge9zUQ@mail.gmail.com","threadId":"54693","inReplyTo":"20201123202003.GB132317@mit.edu","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-23T20:34:18Z","receivedAt":"2020-11-23T20:34:34Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 23, 2020 at 2:20 PM Theodore Y. Ts'o wrote:\n>\n> On Mon, Nov 23, 2020 at 01:40:38PM -0600, Felipe Contreras wrote:\n> > On Mon, Nov 23, 2020 at 1:17 PM Theodore Y. Ts'o wrote:\n> >\n> > > If your repository is effectively a leaf repo, then rebasing may be\n> > > harmless, although there are still who don't like rebasing because it\n> > > invalidates your previous testing. My personal preference is to do a\n> > > git fetch, followed by a git merge --ff-only, and if that errors out,\n> > > then I know I need to take a bit more care before deciding what to do\n> > > next.\n> >\n> > Which is why I suggested to make fast-forward-only the default:\n> >\n> > https://lore.kernel.org/git/1398988808-29678-1-git-send-email-felipe.contreras@gmail.com/\n> >\n> > In what case would that default not be what most people want?\n>\n> Well, it *was* the default, previously, IIRC.\n\nThere has never been a \"pull.mode=ff-only\" option; that's what I tried\nto introduce.\n\n> The problem is that for\n> \"simple\" use cases, using rebases for git-pull is \"simpler\". Well,\n> it's simpler until it does something super-surprising when the project\n> becomes more complex, but if the goal is to have a more gentle\n> learning curve for newbies, especially for small projects --- which\n> are the vast majority of projectds, on, say github and sourceforge ---\n> the case can be made.\n\nThe people that want rebases can configure git pull to do rebases.\n\nThis issue is about the *unconfigured* default.\n\n> So intead of having a huge discussion which is going to be very hard\n> to come to converge (much like the \"main\" vs \"master\" question),\n> requiring people to set their own global default or per-repo default\n> is a pretty good compromise.\n\nThis discussion already happened in 2014, and the conclusion was that\ndoing fast-forward merge if possible, and fail otherwise was a good\ndefault.\n\nThe problem is that the patches were never merged.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"410575","messageId":"X7wuMvHRURK1QS/Q@coredump.intra.peff.net","threadId":"54693","inReplyTo":"CAMP44s27oEjScrJjeDVoNcWcvRsn173L_Kx+TOPfchOwge9zUQ@mail.gmail.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-11-23T21:48:34Z","receivedAt":"2020-11-23T21:48:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 23, 2020 at 02:34:18PM -0600, Felipe Contreras wrote:\n\n> > > Which is why I suggested to make fast-forward-only the default:\n> > >\n> > > https://lore.kernel.org/git/1398988808-29678-1-git-send-email-felipe.contreras@gmail.com/\n> > >\n> > > In what case would that default not be what most people want?\n> >\n> > Well, it *was* the default, previously, IIRC.\n> \n> There has never been a \"pull.mode=ff-only\" option; that's what I tried\n> to introduce.\n\nThere is pull.ff=only these days, which also squelches the message. But\nyou're right that it was never the default.\n\nThe default has continued to be merging. If we were going to switch that\nto bailing out and doing nothing with a warning, I agree that doing so\nonly in the non-fast-forward case would be much better (because in that\ncase, all three modes have the same result).\n\nI don't recall whether there is any active plan to move away from the\nmerge default, though.\n\n-Peff\n"},{"id":"410578","messageId":"CAMMLpeS2e2dFjPHC7N5O67QTo48cpvWEHiU8E55w9YYP4MU0MQ@mail.gmail.com","threadId":"54693","inReplyTo":"X7wuMvHRURK1QS/Q@coredump.intra.peff.net","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2020-11-23T22:03:07Z","receivedAt":"2020-11-23T22:03:45Z","isPatch":false,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Mon, Nov 23, 2020 at 2:48 PM Jeff King wrote:\n>\n> On Mon, Nov 23, 2020 at 02:34:18PM -0600, Felipe Contreras wrote:\n>\n> > > > Which is why I suggested to make fast-forward-only the default:\n> > > >\n> > > > https://lore.kernel.org/git/1398988808-29678-1-git-send-email-felipe.contreras@gmail.com/\n> > > >\n> > > > In what case would that default not be what most people want?\n> > >\n> > > Well, it *was* the default, previously, IIRC.\n> >\n> > There has never been a \"pull.mode=ff-only\" option; that's what I tried\n> > to introduce.\n>\n> There is pull.ff=only these days, which also squelches the message. But\n> you're right that it was never the default.\n>\n> The default has continued to be merging. If we were going to switch that\n> to bailing out and doing nothing with a warning, I agree that doing so\n> only in the non-fast-forward case would be much better (because in that\n> case, all three modes have the same result).\n\nI'd be fine with making fast-forward-only the default. But then again,\nsome users like to set pull.ff=no, which creates a merge commit even\nwhen fast-forwarding is possible. The existence of that workflow might\nbe a good reason to require the user to always be explicit.\n\n> I don't recall whether there is any active plan to move away from the\n> merge default, though.\n\nThere's no formal plan yet. I didn't want to propose anything until\npeople had gotten used to explicitly setting the reconciliation\nstrategy. However, it has been on my long-term radar ever since the\nwarning was added.\n\n-Alex\n"},{"id":"410583","messageId":"xmqq360zn1ez.fsf@gitster.c.googlers.com","threadId":"54693","inReplyTo":"X7wuMvHRURK1QS/Q@coredump.intra.peff.net","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-11-23T22:39:16Z","receivedAt":"2020-11-23T22:39:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I don't recall whether there is any active plan to move away from the\n> merge default, though.\n\nI don't, either, but if we were to do so, keeping the warning/advice\nbeing discussed is crucial to avoid breakage. \n\nHopefully by now most existing users who would have depended on\nunconfigured default behaviour of merging have explicitly shown\ntheir preference by setting the configuration to squelch the\nmessage, so it might not be such a huge backward compatibility\nnightmare. I dunno.\n\n"},{"id":"410589","messageId":"CAMP44s0QOcMnYQqFFSE1jV_T6=e4=xTM0zr_06C6+aYb7oqb4A@mail.gmail.com","threadId":"54693","inReplyTo":"X7wuMvHRURK1QS/Q@coredump.intra.peff.net","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-23T22:55:31Z","receivedAt":"2020-11-23T22:56:14Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 23, 2020 at 3:48 PM Jeff King wrote:\n> On Mon, Nov 23, 2020 at 02:34:18PM -0600, Felipe Contreras wrote:\n\n> > There has never been a \"pull.mode=ff-only\" option; that's what I tried\n> > to introduce.\n>\n> There is pull.ff=only these days, which also squelches the message. But\n> you're right that it was never the default.\n\nBut that's not the same thing. The whole point of \"pull.mode=ff-only\"\nwas to print a message like:\n\n The pull was not fast-forward, please either merge or rebase.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"410607","messageId":"X7xV5SyvCi3ojYz6@coredump.intra.peff.net","threadId":"54693","inReplyTo":"CAMMLpeS2e2dFjPHC7N5O67QTo48cpvWEHiU8E55w9YYP4MU0MQ@mail.gmail.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-11-24T00:37:57Z","receivedAt":"2020-11-24T00:38:02Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 23, 2020 at 03:03:07PM -0700, Alex Henrie wrote:\n\n> > The default has continued to be merging. If we were going to switch that\n> > to bailing out and doing nothing with a warning, I agree that doing so\n> > only in the non-fast-forward case would be much better (because in that\n> > case, all three modes have the same result).\n> \n> I'd be fine with making fast-forward-only the default. But then again,\n> some users like to set pull.ff=no, which creates a merge commit even\n> when fast-forwarding is possible. The existence of that workflow might\n> be a good reason to require the user to always be explicit.\n\nGood point. I was thinking there was no option the users could set where\nthey'd be disappointed by a fast-forward, and for all other cases we'd\nstop and ask the user to tell us more explicitly what they want. But\nyou're right that pull.ff=no is an exception there.\n\nIt might still be OK to allow it by default, though as we have always\nallowed a fast-forward merge by default. So this would be a strict\ntightening from the long-standing behavior of \"if fast-forward, do that;\notherwise, merge\" to \"if fast-forward, do that; otherwise punt\". Anybody\nwho wants pull.ff=no already had to configure it.\n\n-Peff\n"},{"id":"410608","messageId":"X7xWSs3/vVqKl6sK@coredump.intra.peff.net","threadId":"54693","inReplyTo":"CAMP44s0QOcMnYQqFFSE1jV_T6=e4=xTM0zr_06C6+aYb7oqb4A@mail.gmail.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-11-24T00:39:38Z","receivedAt":"2020-11-24T00:40:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 23, 2020 at 04:55:31PM -0600, Felipe Contreras wrote:\n\n> On Mon, Nov 23, 2020 at 3:48 PM Jeff King wrote:\n> > On Mon, Nov 23, 2020 at 02:34:18PM -0600, Felipe Contreras wrote:\n> \n> > > There has never been a \"pull.mode=ff-only\" option; that's what I tried\n> > > to introduce.\n> >\n> > There is pull.ff=only these days, which also squelches the message. But\n> > you're right that it was never the default.\n> \n> But that's not the same thing. The whole point of \"pull.mode=ff-only\"\n> was to print a message like:\n> \n> The pull was not fast-forward, please either merge or rebase.\n\nPerhaps I don't understand the distinction you are making. I have\npull.ff=ff set, and I get:\n\n $ git pull\n remote: Enumerating objects: 1, done.\n remote: Counting objects: 100% (1/1), done.\n remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0\n Receiving objects: 100% (1/1), done.\n From /home/peff/tmp/.\n a4f00e2..22a4151 master -> origin/master\n fatal: Not possible to fast-forward, aborting.\n\nWhich sounds like the same thing, modulo the error message not being\nnearly as helpful (which I would be happy to see rectified).\n\nIs there some other difference you're thinking of?\n\n-Peff\n"},{"id":"410612","messageId":"CAMP44s1Z4tDXO4jstGMtYVOYzkQQnZMHp45pYPOimk+=jwFHcw@mail.gmail.com","threadId":"54693","inReplyTo":"X7xWSs3/vVqKl6sK@coredump.intra.peff.net","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-24T00:57:17Z","receivedAt":"2020-11-24T00:57:54Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 23, 2020 at 6:39 PM Jeff King wrote:\n> On Mon, Nov 23, 2020 at 04:55:31PM -0600, Felipe Contreras wrote:\n> > On Mon, Nov 23, 2020 at 3:48 PM Jeff King wrote:\n\n> > > There is pull.ff=only these days, which also squelches the message. But\n> > > you're right that it was never the default.\n> >\n> > But that's not the same thing. The whole point of \"pull.mode=ff-only\"\n> > was to print a message like:\n> >\n> > The pull was not fast-forward, please either merge or rebase.\n>\n> Perhaps I don't understand the distinction you are making. I have\n> pull.ff=ff set, and I get:\n\nYou mean \"pull.ff=only\" ?\n\n> $ git pull\n\nTry the same thing with \"pull.rebase=true\".\n\n> Which sounds like the same thing, modulo the error message not being\n> nearly as helpful (which I would be happy to see rectified).\n>\n> Is there some other difference you're thinking of?\n\nIt's mainly the error message, but also the fact that pull.ff is\nignored when rebasing.\n\nAdditionally, using \"pull.mode=default\", I introduced the following warning:\n\n The pull was not fast-forward, in the future you would have to\n choose a merge or a rebase, falling back to old style for now (git\n pull --merge).\n Read 'git pull --help' for more information.\"\n\nWhich was triggered *only* when pull.mode wasn't set, *and* the merge\nwasn't fast-forward.\n\nThis warning would have been much better than what we have now. I think.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"410615","messageId":"X7xgow4pchnhf2iY@coredump.intra.peff.net","threadId":"54693","inReplyTo":"CAMP44s1Z4tDXO4jstGMtYVOYzkQQnZMHp45pYPOimk+=jwFHcw@mail.gmail.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-11-24T01:23:47Z","receivedAt":"2020-11-24T01:24:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 23, 2020 at 06:57:17PM -0600, Felipe Contreras wrote:\n\n> > > But that's not the same thing. The whole point of \"pull.mode=ff-only\"\n> > > was to print a message like:\n> > >\n> > > The pull was not fast-forward, please either merge or rebase.\n> >\n> > Perhaps I don't understand the distinction you are making. I have\n> > pull.ff=ff set, and I get:\n> \n> You mean \"pull.ff=only\" ?\n\nEr, yeah, sorry.\n\n> > $ git pull\n> \n> Try the same thing with \"pull.rebase=true\".\n\nAh, that's what I was missing. I agree it would be nice for it to behave\nconsistently in both cases (though why one would set both pull.ff=only\nand pull.rebase=true, I don't know).\n\n-Peff\n"},{"id":"410618","messageId":"xmqqy2irjy4f.fsf@gitster.c.googlers.com","threadId":"54693","inReplyTo":"X7xgow4pchnhf2iY@coredump.intra.peff.net","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-11-24T02:18:40Z","receivedAt":"2020-11-24T02:19:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Ah, that's what I was missing. I agree it would be nice for it to behave\n> consistently in both cases (though why one would set both pull.ff=only\n> and pull.rebase=true, I don't know).\n\nSo an obvious thing we could do, if pull.mode is too much of a\nchange, is to make \"pull --rebase\" codepath honor pull.ff as well,\nperhaps? I.e. those who set pull.ff=only are saying that \"please\nstop me when I have any local change---I want to be notified if my\npull on this branch results in anything but a fast-forward from the\nupstream\".\n\nAnd then making an unconfigured pull.ff to default to pull.ff=only\nmay give a proper failure whether you merge or rebase. I dunno.\n"},{"id":"410620","messageId":"X7xw0xb9UnGKbS8m@coredump.intra.peff.net","threadId":"54693","inReplyTo":"xmqqy2irjy4f.fsf@gitster.c.googlers.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-11-24T02:32:51Z","receivedAt":"2020-11-24T02:33:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 23, 2020 at 06:18:40PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Ah, that's what I was missing. I agree it would be nice for it to behave\n> > consistently in both cases (though why one would set both pull.ff=only\n> > and pull.rebase=true, I don't know).\n> \n> So an obvious thing we could do, if pull.mode is too much of a\n> change, is to make \"pull --rebase\" codepath honor pull.ff as well,\n> perhaps? I.e. those who set pull.ff=only are saying that \"please\n> stop me when I have any local change---I want to be notified if my\n> pull on this branch results in anything but a fast-forward from the\n> upstream\".\n> \n> And then making an unconfigured pull.ff to default to pull.ff=only\n> may give a proper failure whether you merge or rebase. I dunno.\n\nYeah, I would be perfectly happy with that (and it's in fact what I\n_thought_ was happening before today's discussion).\n\nI do wonder if anybody has set:\n\n pull.rebase=true\n pull.ff=only\n\nwhich would then refuse to rebase at all, and whether they would be\nannoyed. I am scratching my head over why one would do that, though. It\nis meaningful only if you usually rebase, but when you say \"--no-rebase\"\nyou want to make sure you do not create a merge commit. Which seems\nweird.\n\n-Peff\n"},{"id":"410629","messageId":"CAMP44s08mEyYqbjOeTeS46CngrbQMqP2=cMr1dtRLLk_BLAq3w@mail.gmail.com","threadId":"54693","inReplyTo":"X7xw0xb9UnGKbS8m@coredump.intra.peff.net","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-24T03:41:05Z","receivedAt":"2020-11-24T03:41:40Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 23, 2020 at 8:32 PM Jeff King wrote:\n> On Mon, Nov 23, 2020 at 06:18:40PM -0800, Junio C Hamano wrote:\n\n> > So an obvious thing we could do, if pull.mode is too much of a\n> > change, is to make \"pull --rebase\" codepath honor pull.ff as well,\n> > perhaps? I.e. those who set pull.ff=only are saying that \"please\n> > stop me when I have any local change---I want to be notified if my\n> > pull on this branch results in anything but a fast-forward from the\n> > upstream\".\n> >\n> > And then making an unconfigured pull.ff to default to pull.ff=only\n> > may give a proper failure whether you merge or rebase. I dunno.\n>\n> Yeah, I would be perfectly happy with that (and it's in fact what I\n> _thought_ was happening before today's discussion).\n>\n> I do wonder if anybody has set:\n>\n> pull.rebase=true\n> pull.ff=only\n>\n> which would then refuse to rebase at all, and whether they would be\n> annoyed. I am scratching my head over why one would do that, though. It\n> is meaningful only if you usually rebase, but when you say \"--no-rebase\"\n> you want to make sure you do not create a merge commit. Which seems\n> weird.\n\nI think you are losing track of the goal.\n\nThe goal is that *eventually*:\n\n1. No warning is issued\n2. No configuration is needed\n3. The default behavior is sane.\n\nThe whole point of \"pull.rebase=ff-only\" (aka. \"pull.mode=ff-only\")\nwas to make it the *default*.\n\nIf you make \"pull.ff=only\" the default, *and* you make \"git pull\n--rebase\" respect that, then \"git pull --rebase\" will fail by default\n(unless it's a fast-forward).\n\nWhat we really need is something like:\n\n1. git pull # fail by default unless it's a fast-forward\n2. git pull --merge # force a merge (unless it's a fast-forward,\ndepending on pull.ff)\n3. git pull --rebase # force a rebase (unless it's a fast-forward,\ndepending on pull.ff)\n\nTherefore, what we really want is \"git pull --rebase\" *ignore*\n\"pull.ff=only\" (a possible default) or ignore \"pull.rebase=ff-only\"\n(also another possible default).\n\nIt would be possible to do something like:\n\n if (!opt_rebase && (!opt_ff || !strcmp(opt_ff, \"--ff-only\")))\n turn_default_behavior = 1;\n\nBut then how would we distinguish between \"git pull\", and \"git pull\n--no-rebase\" (aka. \"git pull --merge\" / \"pull.rebase=false\")?\n\n\nThis is just too much unnecessary complication There's no need to\nentertain a dozen possible heuristics to avoid \"pull.mode\", none of\nwhich avoid breaking existing behavior.\n\nLet's just accept we need push.mode, and then we can have everything:\ndefault, ff-only, merge, rebase.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"410641","messageId":"X7y0GbBQa0a5Alh0@coredump.intra.peff.net","threadId":"54693","inReplyTo":"CAMP44s08mEyYqbjOeTeS46CngrbQMqP2=cMr1dtRLLk_BLAq3w@mail.gmail.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-11-24T07:19:53Z","receivedAt":"2020-11-24T07:20:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 23, 2020 at 09:41:05PM -0600, Felipe Contreras wrote:\n\n> What we really need is something like:\n> \n> 1. git pull # fail by default unless it's a fast-forward\n> 2. git pull --merge # force a merge (unless it's a fast-forward,\n> depending on pull.ff)\n> 3. git pull --rebase # force a rebase (unless it's a fast-forward,\n> depending on pull.ff)\n> \n> Therefore, what we really want is \"git pull --rebase\" *ignore*\n> \"pull.ff=only\" (a possible default) or ignore \"pull.rebase=ff-only\"\n> (also another possible default).\n\nYep. After reading the first half of your mail, I started to respond\nwith the exact same thing. The key thing is letting the command-line\noptions override all of the related config. But I guess after reading to\nthe end that you don't actually like this. ;)\n\nI do agree it would be more clear in the long run with a single option\n(config and command-line) that makes it clear the values are mutually\nexclusive. I'm just not sure if it's painful to get there without\nbreaking compatibility or introducing confusion in the meantime.\n\n> It would be possible to do something like:\n> \n> if (!opt_rebase && (!opt_ff || !strcmp(opt_ff, \"--ff-only\")))\n> turn_default_behavior = 1;\n> \n> But then how would we distinguish between \"git pull\", and \"git pull\n> --no-rebase\" (aka. \"git pull --merge\" / \"pull.rebase=false\")?\n\nI'm not sure what you mean. We can tell the difference between those\nbased on what we saw on the command-line option. I.e., your\n\"!opt_rebase\" is really a tri-state, which allows something like:\n\n if (opt_rebase == REBASE_UNSET) {\n if (opt_ff == FF_UNSET)\n\t opt_ff = ff_default; /* from config or baked-in */\n\t }\n\t opt_rebase = rebase_default;\n }\n\nbut I didn't look at the logic in git-pull.\n\nThat said...\n\n> This is just too much unnecessary complication There's no need to\n> entertain a dozen possible heuristics to avoid \"pull.mode\", none of\n> which avoid breaking existing behavior.\n> \n> Let's just accept we need push.mode, and then we can have everything:\n> default, ff-only, merge, rebase.\n\nI think it could be possible for the documentation to make clear the\ninteractions, especially if the feature is designed with eventual\ndeprecation of other options (e.g., if it says \"pull.mode=ff-only\" means\nthat pull.ff won't be examined, and there's no need to ever use it\nanymore).\n\n-Peff\n"},{"id":"410643","messageId":"CAMP44s31OqnRnMO3bcO43VyUCP27o8UGPA5ognGi1s8Se+CRiw@mail.gmail.com","threadId":"54693","inReplyTo":"X7y0GbBQa0a5Alh0@coredump.intra.peff.net","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-24T07:48:56Z","receivedAt":"2020-11-24T07:49:31Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Nov 24, 2020 at 1:19 AM Jeff King wrote:\n>\n> On Mon, Nov 23, 2020 at 09:41:05PM -0600, Felipe Contreras wrote:\n>\n> > What we really need is something like:\n> >\n> > 1. git pull # fail by default unless it's a fast-forward\n> > 2. git pull --merge # force a merge (unless it's a fast-forward,\n> > depending on pull.ff)\n> > 3. git pull --rebase # force a rebase (unless it's a fast-forward,\n> > depending on pull.ff)\n> >\n> > Therefore, what we really want is \"git pull --rebase\" *ignore*\n> > \"pull.ff=only\" (a possible default) or ignore \"pull.rebase=ff-only\"\n> > (also another possible default).\n>\n> Yep. After reading the first half of your mail, I started to respond\n> with the exact same thing. The key thing is letting the command-line\n> options override all of the related config. But I guess after reading to\n> the end that you don't actually like this. ;)\n\nYes, the command-line options should override the configuration, and\nthe configuration should override the default.\n\nI'm not sure what makes you think I wouldn't like that.\n\n> I do agree it would be more clear in the long run with a single option\n> (config and command-line) that makes it clear the values are mutually\n> exclusive. I'm just not sure if it's painful to get there without\n> breaking compatibility or introducing confusion in the meantime.\n\nI think it is possible. I did the patches several years ago. And I'm\nworking on the patches right now. We'll see.\n\n> > It would be possible to do something like:\n> >\n> > if (!opt_rebase && (!opt_ff || !strcmp(opt_ff, \"--ff-only\")))\n> > turn_default_behavior = 1;\n> >\n> > But then how would we distinguish between \"git pull\", and \"git pull\n> > --no-rebase\" (aka. \"git pull --merge\" / \"pull.rebase=false\")?\n>\n> I'm not sure what you mean. We can tell the difference between those\n> based on what we saw on the command-line option. I.e., your\n> \"!opt_rebase\" is really a tri-state, which allows something like:\n>\n> if (opt_rebase == REBASE_UNSET) {\n> if (opt_ff == FF_UNSET)\n> opt_ff = ff_default; /* from config or baked-in */\n> }\n> opt_rebase = rebase_default;\n> }\n>\n> but I didn't look at the logic in git-pull.\n\nWell, in git-pull there's a callback called: parse_opt_rebase(), and\nif no argument is passed, then it returns REBASE_FALSE (0).\n\nThe rest of the code assumes 0 is no-rebase (i.e. merge).\n\nThere's no REBASE_UNSET.\n\nGranted, it may be possible to change all the code, introduce a\nREBASE_UNSET, and make it so 0 is not REBASE_FALSE, and so on.\nAdditionally, the code that deals with the configuration part needs to\nbe changed too.\n\nI'd rather not.\n\n> > This is just too much unnecessary complication There's no need to\n> > entertain a dozen possible heuristics to avoid \"pull.mode\", none of\n> > which avoid breaking existing behavior.\n> >\n> > Let's just accept we need push.mode, and then we can have everything:\n> > default, ff-only, merge, rebase.\n>\n> I think it could be possible for the documentation to make clear the\n> interactions, especially if the feature is designed with eventual\n> deprecation of other options (e.g., if it says \"pull.mode=ff-only\" means\n> that pull.ff won't be examined, and there's no need to ever use it\n> anymore).\n\nI'm not sure there will be no need for \"pull.ff\". Even with\n\"pull.mode=ff-only\", you should be able to do \"git pull --merge\"\n(should override the configured mode), in which case pull.ff will be\nconsidered (and maybe in \"git pull --rebase\" too).\n\nRegarding the documentation; I think it should be possible to describe\nthe interactions clearly, but as a sequence of overrides, and when no\noverride is specified (default) do something sensible (which right now\nit's quite complex to determine).\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"410645","messageId":"X7y/OdcoVnBeEVju@coredump.intra.peff.net","threadId":"54693","inReplyTo":"CAMP44s31OqnRnMO3bcO43VyUCP27o8UGPA5ognGi1s8Se+CRiw@mail.gmail.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-11-24T08:07:21Z","receivedAt":"2020-11-24T08:07:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 24, 2020 at 01:48:56AM -0600, Felipe Contreras wrote:\n\n> > Yep. After reading the first half of your mail, I started to respond\n> > with the exact same thing. The key thing is letting the command-line\n> > options override all of the related config. But I guess after reading to\n> > the end that you don't actually like this. ;)\n> \n> Yes, the command-line options should override the configuration, and\n> the configuration should override the default.\n> \n> I'm not sure what makes you think I wouldn't like that.\n\nI think it's obvious that \"--rebase\" should override \"pull.rebase\". But\nwhat I thought you were suggesting (and which I think is reasonable) is\nfor \"--rebase\" to affect pull.ff, as well. That's less clear (and\ndoesn't happen now), but I think could produce sensible semantics.\n\nBut it sounded like you thought that was too complicated.\n\n> > I do agree it would be more clear in the long run with a single option\n> > (config and command-line) that makes it clear the values are mutually\n> > exclusive. I'm just not sure if it's painful to get there without\n> > breaking compatibility or introducing confusion in the meantime.\n> \n> I think it is possible. I did the patches several years ago. And I'm\n> working on the patches right now. We'll see.\n\nOK. Then I'm happy to wait and see.\n\n> Well, in git-pull there's a callback called: parse_opt_rebase(), and\n> if no argument is passed, then it returns REBASE_FALSE (0).\n> \n> The rest of the code assumes 0 is no-rebase (i.e. merge).\n> \n> There's no REBASE_UNSET.\n\nRight, I meant that you would add one. But if you are pursuing the other\noption, we can see how that goes.\n\n-Peff\n"},{"id":"410653","messageId":"ab50a108-0df0-e9b6-1d96-f929c513a5b9@redhat.com","threadId":"54693","inReplyTo":"CAMP44s08mEyYqbjOeTeS46CngrbQMqP2=cMr1dtRLLk_BLAq3w@mail.gmail.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Vít Ondruch","fromEmail":"vondruch@redhat.com","sentAt":"2020-11-24T10:35:03Z","receivedAt":"2020-11-24T10:35:38Z","isPatch":false,"sender":{"key":"vondruch@redhat.com","avatar":"https://gravatar.com/avatar/a970a28d3861748910124659b43dbb020284a26b591f29cd27c126284e44bfa3?d=mp&s=160"},"body":"\nDne 24. 11. 20 v 4:41 Felipe Contreras napsal(a):\n> On Mon, Nov 23, 2020 at 8:32 PM Jeff King wrote:\n>> On Mon, Nov 23, 2020 at 06:18:40PM -0800, Junio C Hamano wrote:\n>>> So an obvious thing we could do, if pull.mode is too much of a\n>>> change, is to make \"pull --rebase\" codepath honor pull.ff as well,\n>>> perhaps? I.e. those who set pull.ff=only are saying that \"please\n>>> stop me when I have any local change---I want to be notified if my\n>>> pull on this branch results in anything but a fast-forward from the\n>>> upstream\".\n>>>\n>>> And then making an unconfigured pull.ff to default to pull.ff=only\n>>> may give a proper failure whether you merge or rebase. I dunno.\n>> Yeah, I would be perfectly happy with that (and it's in fact what I\n>> _thought_ was happening before today's discussion).\n>>\n>> I do wonder if anybody has set:\n>>\n>> pull.rebase=true\n>> pull.ff=only\n>>\n>> which would then refuse to rebase at all, and whether they would be\n>> annoyed. I am scratching my head over why one would do that, though. It\n>> is meaningful only if you usually rebase, but when you say \"--no-rebase\"\n>> you want to make sure you do not create a merge commit. Which seems\n>> weird.\n> I think you are losing track of the goal.\n>\n> The goal is that *eventually*:\n>\n> 1. No warning is issued\n> 2. No configuration is needed\n> 3. The default behavior is sane.\n>\n> The whole point of \"pull.rebase=ff-only\" (aka. \"pull.mode=ff-only\")\n> was to make it the *default*.\n>\n> If you make \"pull.ff=only\" the default, *and* you make \"git pull\n> --rebase\" respect that, then \"git pull --rebase\" will fail by default\n> (unless it's a fast-forward).\n>\n> What we really need is something like:\n>\n> 1. git pull # fail by default unless it's a fast-forward\n> 2. git pull --merge # force a merge (unless it's a fast-forward,\n> depending on pull.ff)\n> 3. git pull --rebase # force a rebase (unless it's a fast-forward,\n> depending on pull.ff)\n\n\nThis is the default I would expect.\n\n\nVít\n\n\n"},{"id":"410704","messageId":"CAMMLpeSoGtqeCm6u-zrHqvPhW7brvNk_kwde3uqmbPcP1JgMHg@mail.gmail.com","threadId":"54693","inReplyTo":"CAMP44s08mEyYqbjOeTeS46CngrbQMqP2=cMr1dtRLLk_BLAq3w@mail.gmail.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2020-11-24T20:21:57Z","receivedAt":"2020-11-24T20:22:13Z","isPatch":false,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Mon, Nov 23, 2020 at 8:41 PM Felipe Contreras\n wrote:\n>\n> 1. git pull # fail by default unless it's a fast-forward\n> 2. git pull --merge # force a merge (unless it's a fast-forward,\n> depending on pull.ff)\n> 3. git pull --rebase # force a rebase (unless it's a fast-forward,\n> depending on pull.ff)\n\nI'm not sure that we need a new --merge flag for this. It sounds like\nwe just want pull.ff to default to \"only\" if pull.rebase is not set,\nand if pull.rebase is set (or --rebase or --no-rebase is passed on the\ncommand line) then pull.ff should default to \"true\". If I understand\ncorrectly, that would get us everything we want without adding any new\nvariables or making any major changes to how Git works.\n\n-Alex\n"},{"id":"410723","messageId":"CAMP44s2z3vv2LwoMesydVL3qWrJh0VvHSUy+FpnqguoipRRD9g@mail.gmail.com","threadId":"54693","inReplyTo":"CAMMLpeSoGtqeCm6u-zrHqvPhW7brvNk_kwde3uqmbPcP1JgMHg@mail.gmail.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-24T22:11:47Z","receivedAt":"2020-11-24T22:12:13Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Nov 24, 2020 at 2:22 PM Alex Henrie wrote:\n>\n> On Mon, Nov 23, 2020 at 8:41 PM Felipe Contreras\n> wrote:\n> >\n> > 1. git pull # fail by default unless it's a fast-forward\n> > 2. git pull --merge # force a merge (unless it's a fast-forward,\n> > depending on pull.ff)\n> > 3. git pull --rebase # force a rebase (unless it's a fast-forward,\n> > depending on pull.ff)\n>\n> I'm not sure that we need a new --merge flag for this. It sounds like\n> we just want pull.ff to default to \"only\" if pull.rebase is not set,\n> and if pull.rebase is set (or --rebase or --no-rebase is passed on the\n> command line) then pull.ff should default to \"true\". If I understand\n> correctly, that would get us everything we want without adding any new\n> variables or making any major changes to how Git works.\n\nBefore making \"pull.ff=only\" the default, we need a transitional\nperiod in which if it's unset, a warning is printed when pulling a\nnon-fast-forward branch. This is what my patch did several years ago.\n\nAnd yes, it should be possible to do what you suggest, but have you\ntried? I suspect both the code and the documentation would be quite\nconvoluted.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"410730","messageId":"CAMMLpeQvofhPjcJ19JrqJs1W3YoQSP+hOainuZJa=QeJzYc+5w@mail.gmail.com","threadId":"54693","inReplyTo":"CAMP44s2z3vv2LwoMesydVL3qWrJh0VvHSUy+FpnqguoipRRD9g@mail.gmail.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2020-11-24T23:23:49Z","receivedAt":"2020-11-24T23:24:06Z","isPatch":false,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Tue, Nov 24, 2020 at 3:11 PM Felipe Contreras\n wrote:\n>\n> Before making \"pull.ff=only\" the default, we need a transitional\n> period in which if it's unset, a warning is printed when pulling a\n> non-fast-forward branch. This is what my patch did several years ago.\n\nWe'd only need a warning if both pull.ff and pull.rebase are unset,\nsince that's the only situation where the behavior would change. And\nprovidentially, we already have a warning in that exact case, although\nwe should probably tweak it to explain what the new behavior is going\nto be :-)\n\n> And yes, it should be possible to do what you suggest, but have you\n> tried? I suspect both the code and the documentation would be quite\n> convoluted.\n\nYes, I have written a very simple patch that implements the behavior\nthat I am suggesting. I will send it to the mailing list later\ntonight.\n\n-Alex\n"},{"id":"410738","messageId":"xmqq7dqagtgx.fsf@gitster.c.googlers.com","threadId":"54693","inReplyTo":"CAMMLpeQvofhPjcJ19JrqJs1W3YoQSP+hOainuZJa=QeJzYc+5w@mail.gmail.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-11-25T00:39:42Z","receivedAt":"2020-11-25T00:40:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Henrie writes:\n\n> We'd only need a warning if both pull.ff and pull.rebase are unset,\n> since that's the only situation where the behavior would change. And\n> providentially, we already have a warning in that exact case, although\n> we should probably tweak it to explain what the new behavior is going\n> to be :-)\n\nIf we were starting \"git pull\" from scratch without any existing\nconfiguration and command line options, pull.mode might present a\nsimpler end user experience, but I have to say that pull.ff and\npull.rebase that are fairly well ingrained in docs and users' minds,\nthe above plan sounds like a better option to reduce the cognitive\noverhead for users.\n\n>> And yes, it should be possible to do what you suggest, but have you\n>> tried? I suspect both the code and the documentation would be quite\n>> convoluted.\n>\n> Yes, I have written a very simple patch that implements the behavior\n> that I am suggesting. I will send it to the mailing list later\n> tonight.\n\nLet's see how well the comparison between two approaches play out.\nThanks.\n"},{"id":"410846","messageId":"CAMP44s0M00sBvdjD0jc0X=1=PJepC5fNndw73sceOpbDCw5dFQ@mail.gmail.com","threadId":"54693","inReplyTo":"xmqq7dqagtgx.fsf@gitster.c.googlers.com","subject":"Re: Pick the right default and stop warn on `git pull`","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2020-11-26T01:02:14Z","receivedAt":"2020-11-26T01:02:44Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Tue, Nov 24, 2020 at 6:39 PM Junio C Hamano wrote:\n>\n> Alex Henrie writes:\n>\n> > We'd only need a warning if both pull.ff and pull.rebase are unset,\n> > since that's the only situation where the behavior would change. And\n> > providentially, we already have a warning in that exact case, although\n> > we should probably tweak it to explain what the new behavior is going\n> > to be :-)\n>\n> If we were starting \"git pull\" from scratch without any existing\n> configuration and command line options, pull.mode might present a\n> simpler end user experience, but I have to say that pull.ff and\n> pull.rebase that are fairly well ingrained in docs and users' minds,\n> the above plan sounds like a better option to reduce the cognitive\n> overhead for users.\n\nIs it? From forums, blogs, and answers in Stack Overflow what I mostly\nsee is \"do not do git pull\".\n\n> >> And yes, it should be possible to do what you suggest, but have you\n> >> tried? I suspect both the code and the documentation would be quite\n> >> convoluted.\n> >\n> > Yes, I have written a very simple patch that implements the behavior\n> > that I am suggesting. I will send it to the mailing list later\n> > tonight.\n>\n> Let's see how well the comparison between two approaches play out.\n> Thanks.\n\nI tried to remove pull.mode from my patch series, and it mostly works,\nexcept if you:\n\n1. Have \"pull.ff=only\"\n2. Do a \"git pull --no-rebase\"\n\nWhen you have \"pull.mode=ff-only\", doing \"git pull --no-rebase\" (\"git\npull --merge\") that mode is overridden, and the merge succeeds.\n\nIf you have \"pull.ff=only\", you would have to do \"git pull --no-rebase\n--no-ff\" for the merge to succeed, which I don't think should be the\ndefault.\n\nWe could change the semantics of \"pull.ff=only\", but that would break\nexisting behavior, and it starts to get convoluted.\n\nCheers.\n\n-- \nFelipe Contreras\n"}]}