{"thread":{"id":"36567","subject":"Pull is Mostly Evil","startedAt":"2014-05-02T15:37:03Z","lastAt":"2014-05-09T19:49:25Z","messageCount":50,"participants":["Marc Branchaud","David Kastrup","Philip Oakley","Junio C Hamano","Felipe Contreras","David Lang","Jeff King","Jonathan Nieder","Richard Hansen","John Szakmeister","James Denholm","Max Kirillov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"240530","messageId":"5363BB9F.40102@xiplink.com","threadId":"36567","inReplyTo":null,"subject":"Pull is Mostly Evil","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2014-05-02T15:37:03Z","receivedAt":"2014-05-02T15:37:03Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"\n(Apologies for not CCing all the folks who've participated in the \"Pull is\nEvil\" thread -- I couldn't find a good branch of that thread for this message.)\n\nOK, so maybe \"git pull\" is just Mostly Evil. People seem to have found many\ndifferent ways to make it work for them.\n\nBut in reality \"git pull\" has become a chimera that confuses a large number\nof new users, and that experienced users either avoid entirely or customize\nto give them a convenient shorthand for working in their particular\nenvironment. As a tool for new git users, it just doesn't seem to be\nachieving its goals.\n\nI think the git project as a whole would benefit if it started to treat \"git\npull\" as an advanced command, in the sense that it needs to be configured by\nan experienced user in order to make it correctly follow a project's\nworkflow. Once it's configured properly, \"git pull\" is a powerful tool that\ngives users an easy way to do complex things. In that sense, it may be\nappropriate for a project to tailor \"git pull\" as it likes, then teach its\nown users to use the command.\n\nHowever, when it comes to teaching people how to use git qua git, \"git pull\"\nshould be the last thing they learn about, because it's only after you\nunderstand various basic git concepts that you can configure \"git pull\" to do\nthe right thing.\n\nTo that end, I suggest that pull's default behaviour should be to do\n*nothing*. It should just print out a message to the effect that it hasn't\nbeen configured, and that the user should run \"git help pull\" for guidance.\n\nIt'll take quite a bit of time, but I think that if we change our attitude\ntowards \"git pull\" and take this unconfigured-by-default approach, then in a\nfew years the entire git ecosystem will be in a better place.\n\n\t\tM.\n"},{"id":"240531","messageId":"87k3a4xjzg.fsf@fencepost.gnu.org","threadId":"36567","inReplyTo":"5363BB9F.40102@xiplink.com","subject":"Re: Pull is Mostly Evil","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-02T15:45:23Z","receivedAt":"2014-05-02T15:45:23Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Marc Branchaud writes:\n\n> To that end, I suggest that pull's default behaviour should be to do\n> *nothing*. It should just print out a message to the effect that it\n> hasn't been configured, and that the user should run \"git help pull\"\n> for guidance.\n\nFetching is uncontentious, and I _think_ that fast-forwards are pretty\nuncontentious as well.\n\nIt's just when the merge-left/merge-right/rebase-left/rebase-right\ndecision kicks in that prescribing one git-pull behavior looks like a\nrecipe for trouble.\n\n-- \nDavid Kastrup\n"},{"id":"240532","messageId":"C439C0C76DA44AB5AAC91E7C0D2991BA@PhilipOakley","threadId":"36567","inReplyTo":"87k3a4xjzg.fsf@fencepost.gnu.org","subject":"Re: Pull is Mostly Evil","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2014-05-02T16:05:29Z","receivedAt":"2014-05-02T16:05:29Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"David Kastrup\" \n> Marc Branchaud writes:\n>\n>> To that end, I suggest that pull's default behaviour should be to do\n>> *nothing*. It should just print out a message to the effect that it\n>> hasn't been configured, and that the user should run \"git help pull\"\n>> for guidance.\n>\n> Fetching is uncontentious, and I _think_ that fast-forwards are pretty\n> uncontentious as well.\n\nWhile the fast forward is /pretty/ uncontentious, it still maybe \ncontentious for some. But more importantly (in my mind) is the fact that \nit (git pull) hasn't been configured, and pressing for _that_ to happen \nis the big benefit.\n\nI'm more than happy that the fast-forward should be the recommended 'if \nyou don't know, choose this' option, as you say, its pretty \nuncontentious and has easy mechanisms for backing out which are well \nillustrated across the internet.\n\nIt would still need a few cycles of ramping up the warnings to ease folk \nin gently. One has to beware of the issues at both ends of the Kruger \nDunning curve. This thread discussion in some ways has suffered from the \ninverse K-D effect.\n\n>\n> It's just when the merge-left/merge-right/rebase-left/rebase-right\n> decision kicks in that prescribing one git-pull behavior looks like a\n> recipe for trouble.\n>\n> -- \n> David Kastrup\n>\n--\nPhilip\n"},{"id":"240539","messageId":"xmqqoazgaw0y.fsf@gitster.dls.corp.google.com","threadId":"36567","inReplyTo":"5363BB9F.40102@xiplink.com","subject":"Re: Pull is Mostly Evil","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-02T18:13:49Z","receivedAt":"2014-05-02T18:13:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n> (Apologies for not CCing all the folks who've participated in the \"Pull is\n> Evil\" thread -- I couldn't find a good branch of that thread for this message.)\n>\n> OK, so maybe \"git pull\" is just Mostly Evil. People seem to have found many\n> different ways to make it work for them.\n>\n> But in reality \"git pull\" has become a chimera that confuses a large number\n> of new users, and that experienced users either avoid entirely or customize\n> to give them a convenient shorthand for working in their particular\n> environment. As a tool for new git users, it just doesn't seem to be\n> achieving its goals.\n>\n> I think the git project as a whole would benefit if it started to treat \"git\n> pull\" as an advanced command, in the sense that it needs to be configured by\n> an experienced user in order to make it correctly follow a project's\n> workflow. Once it's configured properly, \"git pull\" is a powerful tool that\n> gives users an easy way to do complex things. In that sense, it may be\n> appropriate for a project to tailor \"git pull\" as it likes, then teach its\n> own users to use the command.\n>\n> However, when it comes to teaching people how to use git qua git, \"git pull\"\n> should be the last thing they learn about, because it's only after you\n> understand various basic git concepts that you can configure \"git pull\" to do\n> the right thing.\n>\n> To that end, I suggest that pull's default behaviour should be to do\n> *nothing*. It should just print out a message to the effect that it hasn't\n> been configured, and that the user should run \"git help pull\" for guidance.\n>\n> It'll take quite a bit of time, but I think that if we change our attitude\n> towards \"git pull\" and take this unconfigured-by-default approach, then in a\n> few years the entire git ecosystem will be in a better place.\n\nYour earlier long-hand, together with the two examples that pulls\ninto the same \"maint\" branch Brian gave us, may give us a better\nstarting points to think about a saner way.\n\nTo me, the problem sounds like:\n\n Tutorials of Git often says \"use 'git pull' to catch up your\n branch with your upstream work and then 'git push' back\" (and\n worse yet, 'git push' that does not fast-forward suggests doing\n so), but 'git pull' that creates a merge in a wrong direction is\n not the right thing for many people.\n\nAnd proposed solutions range from \"let's write 'pull' off as a\nfailed experiment\" to \"let's forbid any merge made by use of 'pull'\nby default, because it is likely that merge may be in reverse\".\n\nLet's look at Brian's examples, which may point at a good direction.\n\nWhen he becomes in charge of producing a new 'maint' (in his\noriginal, he says 'maintenance-branch'), he first does this:\n\n $ git checkout maint\n $ git pull --ff-only [ origin maint ]\n\nHe may have a stale 'maint' branch for a variety of reasons. He may\nhave been the pumpking in the past, worked on his local 'maint' to\nadvance its tip with merges in the right direction and pushed the\nresult out to the central repository when he was done, and kept that\nthen-current 'maint' in his repository without removing when he\npassed the pumpkin to somebody else. As you said in the thread,\nthis could have been done on a detached head, but keeping the local\nbranch around is more convenient (you may want to do a disconnected\ndevelopment and having a reference point is handy). Or he may be\nthe long-term pumpking for 'maint' branch, but is working on a\nmachine different from the one he updated the shared 'maint' the\nlast time.\n\nIn either case, what is most important for this 'pull' is that he is\ncatching up with today's central repository, without losing any old\nwork that he forgot to push out when he was playing the pumpking the\nlast time (hence --ff-only to cause it to fail if that is the case)\nin this local repository.\n\nThen he integrates a topic by another and push the result with:\n\n $ git pull [--no-ff] developer-remote topic-branch\n $ git push [ origin maint ]\n\nFor this 'pull', he knows that this may not fast-forward (the\n$DAYJOB convention to use a real merge even when the merge\nfast-forwards is optional).\n\nEven with the proposed \"pull.mode\" or \"branch.maint.pullmode\", these\ntwo 'pull' cannot be given a convenient default. The best we can do\nwith the approach is to set pull.mode to ff-only for safety to protect\nhis first 'pull' from the origin/maint, and have him remember to\noverride it from the command line with \"--merge --no-ff\" [*1*].\n\nIf we step back a bit, because we are forcing him to differentiate\nthese two pulls in his mental model anyway, perhaps it may help\npeople (both new and old) if we had a new command to make the\ndistinction stand out more. What if the command sequence were like\nthis instead?\n\n $ git checkout maint\n $ git update [ origin maint ]\n\n $ git pull [--no-ff] developer-remote topic-branch\n $ git push [ origin maint ]\n\nwhere the new command 'update' enforces the '--ff-only' update. And\nthen we would stop telling \"'git pull' first\" when a push does not\nfast-forward.\n\nStepping back even further, and thinking what is different between\nthese two pulls, we notice that the first one is pulling from the\nplace we push back to. Perhaps a way to solve this issue, without\nhaving to introduce a new 'git update' and updating the tutorials,\nmay be disallow fetch+merge by default only when pulling from the\nplace the result is going to be pushed back to? That is one case in\nwhich it is very clear that we are making a merge in the wrong\ndirection. When you are pulling from developer-remote that is not\nwhere you are going to push back, is there a reason to forbid a\nnon-ff pull from creating a merge?\n\nAlso I think what you said in a separate subthread merits more\nthought:\n\n What's more, it seems to me that the only real advantage \"git\n pull\" provides here is a less typing compared to the non-pull\n equivalent:\n\n git fetch main-repo\n git checkout main-repo/maintenance-branch\n git fetch developer-remote\n git merge --no-ff developer-remote/topic-branch\n git push main-repo HEAD\n\n I suggest that this approach is superior for new users (despite\n the increased risk of finger cramps), because if main-repo's\n maintenance-branch is updated in the interim and the push fails,\n the user can use the exact same commands to resolve the\n situation.\n\nI very much like the \"you can easily tell the new person to redo the\nwhole thing when the last push does not fast-forwareed\" aspect of\nthis approach. Maybe a good alternative may be to encapsulate this\nsequence to a handy \"git update\" (which is *NOT* the one I suggested\noff-the-cuff in the above to replace the first 'git pull' in Brian's\nexample---it is more for the second one) wrapper and promote the use\nof that in our tutorials. Perhaps:\n\n $ git checkout maint\n $ git update developer-remote topic-branch\n $ git push [ origin maint ]\n\nthat tells us to fast-forward update the current branch (maint) from\nits upstream (origin), fetch the developer's work and merge it.\nWhen the last 'push' does not fast-forward, that has to be because\nsomebody else pushed (because we already made it up-to-date), so the\nsecond time around, \"git update\" that notices that it cannot\nfast-forward can offer to recreate the merge (or any further work\ndone since the local 'maint' diverged from the origin/maint), before\nredoing the \"git pull developer-remote topic-branch\" phase.\n\nA hypothetical transcript might go like this.\n\n $ git checkout maint\n $ git update developer-remote topic-branch\n ... does a rough equivalent of\n $ git pull --ff-only [ origin maint ]\n $ git pull [--no-ff] developer-remote topic-branch\n $ git push [ origin maint ]\n error: the push does not fast-forward. \"git update\" before\n error: attempting to push again.\n\n $ git update\n ... internally does:\n $ git pull --ff-only [ origin maint ]\n ... which fails due to --ff-only\n info: You have some local work made on an old version of\n info: origin/maint. Let's rebuild it on top of the latest.\n ... does a rough equivalent of\n $ git rebase --preserve-merges origin/maint\n\n $ git push [ origin maint ]\n ... this time it succeeds.\n\nNote that this would also support, without any change, those who\nbuild their own changes directly on top of their 'master' and push\nthe result back to the shared 'master'.\n\nAnd to guard new people who type 'pull' when they meant 'update', \nwe can notice if the pull is coming from the same place origin/maint\nwe will push back to.\n\nHmm?\n\n\n[Footnote]\n\n*1* I do not think it is *wrong* to say \"we won't differentiate\n these two modes; if somebody pulls into the same branch this\n way, he is an integrator and should know better than newbies who\n gets harmed by a merge in the wrong direction\" and stop our\n effort at this point. I would say that is perfectly a valid\n position to take, as long as it is clearly documented: in order\n to help majority of new people, experienced ones are asked to do\n X and Y that they did not have to.\n"},{"id":"240546","messageId":"5363ec734572a_70ef0f30cdc@nysa.notmuch","threadId":"36567","inReplyTo":"C439C0C76DA44AB5AAC91E7C0D2991BA@PhilipOakley","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-02T19:05:23Z","receivedAt":"2014-05-02T19:05:23Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philip Oakley wrote:\n> From: \"David Kastrup\" \n> > Marc Branchaud writes:\n> >\n> >> To that end, I suggest that pull's default behaviour should be to do\n> >> *nothing*. It should just print out a message to the effect that it\n> >> hasn't been configured, and that the user should run \"git help pull\"\n> >> for guidance.\n> >\n> > Fetching is uncontentious, and I _think_ that fast-forwards are pretty\n> > uncontentious as well.\n> \n> While the fast forward is /pretty/ uncontentious, it still maybe \n> contentious for some.\n\nSo? No defaults can please absolutely everyone, the best anybody can do\nis try to please the majority of people, and merging fast-forwards only\ndoes that.\n\n-- \nFelipe Contreras\n"},{"id":"240547","messageId":"5363edc954f8e_70ef0f30c24@nysa.notmuch","threadId":"36567","inReplyTo":"xmqqoazgaw0y.fsf@gitster.dls.corp.google.com","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-02T19:11:05Z","receivedAt":"2014-05-02T19:11:05Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> If we step back a bit, because we are forcing him to differentiate\n> these two pulls in his mental model anyway, perhaps it may help\n> people (both new and old) if we had a new command to make the\n> distinction stand out more. What if the command sequence were like\n> this instead?\n> \n> $ git checkout maint\n> $ git update [ origin maint ]\n> \n> $ git pull [--no-ff] developer-remote topic-branch\n> $ git push [ origin maint ]\n> \n> where the new command 'update' enforces the '--ff-only' update. And\n> then we would stop telling \"'git pull' first\" when a push does not\n> fast-forward.\n\nIn addition to barf when it's not a fast-forward, such command can\nswitch the parents, so it appears 'maint' was merged to 'origin/maint'.\nMany people have complained about this order.\n\n> Stepping back even further, and thinking what is different between\n> these two pulls, we notice that the first one is pulling from the\n> place we push back to. Perhaps a way to solve this issue, without\n> having to introduce a new 'git update' and updating the tutorials,\n> may be disallow fetch+merge by default only when pulling from the\n> place the result is going to be pushed back to?\n\nWhich is basically essentially the same as not specifying anything, or\nrather, running `git pull` without arguments.\n\n-- \nFelipe Contreras\n"},{"id":"240550","messageId":"alpine.DEB.2.02.1405021227161.14881@nftneq.ynat.uz","threadId":"36567","inReplyTo":"87k3a4xjzg.fsf@fencepost.gnu.org","subject":"Re: Pull is Mostly Evil","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2014-05-02T19:31:27Z","receivedAt":"2014-05-02T19:31:27Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 2 May 2014, David Kastrup wrote:\n\n> Date: Fri, 02 May 2014 17:45:23 +0200\n> From: David Kastrup \n> To: git@vger.kernel.org\n> Subject: Re: Pull is Mostly Evil\n> \n> Marc Branchaud writes:\n>\n>> To that end, I suggest that pull's default behaviour should be to do\n>> *nothing*. It should just print out a message to the effect that it\n>> hasn't been configured, and that the user should run \"git help pull\"\n>> for guidance.\n>\n> Fetching is uncontentious, and I _think_ that fast-forwards are pretty\n> uncontentious as well.\n\nso those people just need to use fetch instead of pull.\n\nThis seems fairly straightforward\n\nfetch, get the data but don't integrate it\n\npull, get the data and ff along it if possible\n\npull with options, merge/rebase left/right based on options when ff is not \npossible.\n\nPull was created with one workflow in mind, Changing it to require explcitly \nspecifying the option (in a config, with appropriate transition, handholding) is \nnot completly unreasonable, and given the confusion this causes, may be very \nreasonable.\n\nBut saying that ff isn't always right, so make pull go away altogether (or \n\"don't change anything because there isn't 100% agreement on the result\" \nparalysis) doesn't seem right.\n\n> It's just when the merge-left/merge-right/rebase-left/rebase-right\n> decision kicks in that prescribing one git-pull behavior looks like a\n> recipe for trouble.\n\nconfusion at least. It's not fatal confusion, people have been using it for \nyears after all.\n\nDavid Lang\n"},{"id":"240568","messageId":"8761lox98q.fsf@fencepost.gnu.org","threadId":"36567","inReplyTo":"alpine.DEB.2.02.1405021227161.14881@nftneq.ynat.uz","subject":"Re: Pull is Mostly Evil","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-02T19:37:25Z","receivedAt":"2014-05-02T19:37:25Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"David Lang writes:\n\n> On Fri, 2 May 2014, David Kastrup wrote:\n>\n>> It's just when the merge-left/merge-right/rebase-left/rebase-right\n>> decision kicks in that prescribing one git-pull behavior looks like a\n>> recipe for trouble.\n>\n> confusion at least. It's not fatal confusion, people have been using\n> it for years after all.\n\nIt's one of the most frequent causes for educating newcomers what they\nhave been doing wrong in the LilyPond project. Including the occasional\nblunder from experienced people who did not notice that they got a\nnon-ff merge as a mergeday present.\n\nIt's one of the main things putting new contributors on edge and causing\nanxiety about messing up again.\n\n-- \nDavid Kastrup\n"},{"id":"240557","messageId":"xmqqtx989c9d.fsf@gitster.dls.corp.google.com","threadId":"36567","inReplyTo":"5363edc954f8e_70ef0f30c24@nysa.notmuch","subject":"Re: Pull is Mostly Evil","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-02T20:06:06Z","receivedAt":"2014-05-02T20:06:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n>> Stepping back even further, and thinking what is different between\n>> these two pulls, we notice that the first one is pulling from the\n>> place we push back to. Perhaps a way to solve this issue, without\n>> having to introduce a new 'git update' and updating the tutorials,\n>> may be disallow fetch+merge by default only when pulling from the\n>> place the result is going to be pushed back to?\n>\n> Which is basically essentially the same as not specifying anything, or\n> rather, running `git pull` without arguments.\n\nI cannot tell if you are agreeing or disagreeing, and with what.\n\nUsing the \"special case 'git pull' without arguments\" heuristics\nwould take us back to the old jc/pull-training-wheel patch\n\n http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=230856\n\nwhich we agreed to drop in\n\n http://thread.gmane.org/gmane.comp.version-control.git/233554/focus=234365\n\nto favor the old series you did with pull.mode, and we rejected that\npatch in $gmane/230856 for a sound reason, I would think.\n\n\"You are pulling from the place the result is going to be pushed\nback to\" is different from \"'git pull' was run without arguments\".\nIn the \"pumpking\" example in the message you are responding to:\n\n When he becomes in charge of producing a new 'maint' (in his\n original, he says 'maintenance-branch'), he first does this:\n\n $ git checkout maint\n $ git pull --ff-only [ origin maint ]\n\nthe heuristics would trigger the safety only when the optional\n\"origin maint\" are not given, but we do have enough information\nto see \"git pull origin maint\" (with where from and what to pull\nexplicitly specified on the command line) falls into the case where\nthe user needs protection, don't we?\n\nAlso, with the triangular push configuration, \"git pull\" without\nargument will fetch from one place that is different from where the\ncurrent branch is going to pushed to, so that heuristics would not\nwork at all.\n\nSo...\n"},{"id":"240573","messageId":"53640701f135a_135215292ec1@nysa.notmuch","threadId":"36567","inReplyTo":"xmqqtx989c9d.fsf@gitster.dls.corp.google.com","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-02T20:58:41Z","receivedAt":"2014-05-02T20:58:41Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> >> Stepping back even further, and thinking what is different between\n> >> these two pulls, we notice that the first one is pulling from the\n> >> place we push back to. Perhaps a way to solve this issue, without\n> >> having to introduce a new 'git update' and updating the tutorials,\n> >> may be disallow fetch+merge by default only when pulling from the\n> >> place the result is going to be pushed back to?\n> >\n> > Which is basically essentially the same as not specifying anything, or\n> > rather, running `git pull` without arguments.\n> \n> I cannot tell if you are agreeing or disagreeing, and with what.\n\nI'm agreeing that 'git pull repo branch' is different than 'git pull',\nand 'git pull' is the problem. I'm not certain about 'git pull repo',\nbut I think that probably shouldn't change either.\n\n> Using the \"special case 'git pull' without arguments\" heuristics\n> would take us back to the old jc/pull-training-wheel patch\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=230856\n\nIf you mean adding back the 'test $# = 0', then yes, if you mean going\nback to 'pull.rebase=false' to force merges (and a bunch of other\nstuff), then no.\n\n> which we agreed to drop in\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/233554/focus=234365\n> \n> to favor the old series you did with pull.mode, and we rejected that\n> patch in $gmane/230856 for a sound reason, I would think.\n\nBecause the 'pull.mode=merge' mode option was simply sensible.\n\n> \"You are pulling from the place the result is going to be pushed\n> back to\" is different from \"'git pull' was run without arguments\".\n> In the \"pumpking\" example in the message you are responding to:\n> \n> When he becomes in charge of producing a new 'maint' (in his\n> original, he says 'maintenance-branch'), he first does this:\n> \n> $ git checkout maint\n> $ git pull --ff-only [ origin maint ]\n> \n> the heuristics would trigger the safety only when the optional\n> \"origin maint\" are not given, but we do have enough information\n> to see \"git pull origin maint\" (with where from and what to pull\n> explicitly specified on the command line) falls into the case where\n> the user needs protection, don't we?\n\nI think 'git pull' and 'git pull origin maint' are different, regardless\nof the fact that origin/maint is the upstream.\n\nIn the former I would expect 'maint' to be merged to 'origin/maint', in\nthe latter I would expect 'origin/maint' to be merged into 'maint'. And\nif the user has specified that he wants to merge 'origin/maint' into\n'maint', I don't see why a non-fast-forward should fail.\n \n> Also, with the triangular push configuration, \"git pull\" without\n> argument will fetch from one place that is different from where the\n> current branch is going to pushed to, so that heuristics would not\n> work at all.\n\nI think that's irrelevant. Both the upstream and publish tracking\nbranches don't matter when the user has specifically asked for a branch\nto be pulled.\n\n-- \nFelipe Contreras\n"},{"id":"240577","messageId":"20140502214817.GA10801@sigill.intra.peff.net","threadId":"36567","inReplyTo":"5363edc954f8e_70ef0f30c24@nysa.notmuch","subject":"Re: Pull is Mostly Evil","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-05-02T21:48:17Z","receivedAt":"2014-05-02T21:48:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote:\n\n> Junio C Hamano wrote:\n> > If we step back a bit, because we are forcing him to differentiate\n> > these two pulls in his mental model anyway, perhaps it may help\n> > people (both new and old) if we had a new command to make the\n> > distinction stand out more. What if the command sequence were like\n> > this instead?\n> > \n> > $ git checkout maint\n> > $ git update [ origin maint ]\n> > \n> > $ git pull [--no-ff] developer-remote topic-branch\n> > $ git push [ origin maint ]\n> > \n> > where the new command 'update' enforces the '--ff-only' update. And\n> > then we would stop telling \"'git pull' first\" when a push does not\n> > fast-forward.\n> \n> In addition to barf when it's not a fast-forward, such command can\n> switch the parents, so it appears 'maint' was merged to 'origin/maint'.\n> Many people have complained about this order.\n\nI realize this has veered off into talking about an \"update\" command,\nand not necessarily \"pull\", but since there a lot of proposals floating\naround, I wanted to make one point: if we are going to do such a switch,\nlet's please make it something the user explicitly turns on.\n\nOne common workflow for GitHub users is to back-merge master into a\ntopic, because they want the final \"integrated\" version on the topic\nbranch. That lets it get review, run tests, and even get test-deployed\nfrom there before merging to master (and then when it does merge to\nmaster, we know the result will be a trivial merge). This workflow\nhelps spread out the load (there is no central \"integration\" person or\nscript, and the merge itself becomes a possible part of the review/test\ncycle). Some projects will do this by rebasing the topic, but that has\nits own complications (like making collaboration harder because the\ncommits are being frequently rewritten).\n\nSuch users are going to run \"git pull origin master\" or just \"git pull\"\nto get that merge. A switch to disallowing non-ff is going to disrupt\nthat workflow. I think we can live with that, as they should be able to\nstop and say \"no, my workflow wants these merges\", set a config\nvariable, and be done.\n\nBut I think that is the same moment they should probably be deciding on\nwhether their workflow wants \"regular\" or \"reverse\" merges. And I do not\nthink the decision between the two has an obvious split over which is\nbetter. So it makes sense to me to take the opportunity when the user is\nthinking about their workflow to have them specify one or the other.\n\n-Peff\n"},{"id":"240581","messageId":"536414352fa24_1976139f2f0f9@nysa.notmuch","threadId":"36567","inReplyTo":"20140502214817.GA10801@sigill.intra.peff.net","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-02T21:55:01Z","receivedAt":"2014-05-02T21:55:01Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote:\n> \n> > Junio C Hamano wrote:\n> > > If we step back a bit, because we are forcing him to differentiate\n> > > these two pulls in his mental model anyway, perhaps it may help\n> > > people (both new and old) if we had a new command to make the\n> > > distinction stand out more. What if the command sequence were like\n> > > this instead?\n> > > \n> > > $ git checkout maint\n> > > $ git update [ origin maint ]\n> > > \n> > > $ git pull [--no-ff] developer-remote topic-branch\n> > > $ git push [ origin maint ]\n> > > \n> > > where the new command 'update' enforces the '--ff-only' update. And\n> > > then we would stop telling \"'git pull' first\" when a push does not\n> > > fast-forward.\n> > \n> > In addition to barf when it's not a fast-forward, such command can\n> > switch the parents, so it appears 'maint' was merged to 'origin/maint'.\n> > Many people have complained about this order.\n> \n> I realize this has veered off into talking about an \"update\" command,\n> and not necessarily \"pull\", but since there a lot of proposals floating\n> around, I wanted to make one point: if we are going to do such a switch,\n> let's please make it something the user explicitly turns on.\n\nThis is sensible, but with warning \"X will be the default in the\nfuture\", just like we did with push.default = simple.\n\n> One common workflow for GitHub users is to back-merge master into a\n> topic, because they want the final \"integrated\" version on the topic\n> branch. That lets it get review, run tests, and even get test-deployed\n> from there before merging to master (and then when it does merge to\n> master, we know the result will be a trivial merge). This workflow\n> helps spread out the load (there is no central \"integration\" person or\n> script, and the merge itself becomes a possible part of the review/test\n> cycle). Some projects will do this by rebasing the topic, but that has\n> its own complications (like making collaboration harder because the\n> commits are being frequently rewritten).\n\nThey can do:\n\n% git pull origin master\n\nThat shouldn't revese the bases.\n\n> Such users are going to run \"git pull origin master\" or just \"git pull\"\n> to get that merge.\n\nI'd say the vast majority of users running \"git pull\" want the parents\nreversed, the minority that doesn't can switch to \"git pull origin\nmaster\" (or add a configuration).\n\n> A switch to disallowing non-ff is going to disrupt\n> that workflow.\n\nOnly if the refuse to do \"git pull origin master\".\n\n> But I think that is the same moment they should probably be deciding on\n> whether their workflow wants \"regular\" or \"reverse\" merges. And I do not\n> think the decision between the two has an obvious split over which is\n> better.\n\nBecause there hasn't been enough discussion on this topic. I'm fairly\ncertain there will be consensus once concrete proposals are properly\ndiscussed.\n\nMost likely the consensus and the proposals will be ignored and nothing\nwill change as usual, but that's a different thing.\n\n-- \nFelipe Contreras\n"},{"id":"240583","messageId":"B2C7522180DD4894BB18B91CAFD35FF9@PhilipOakley","threadId":"36567","inReplyTo":"5363BB9F.40102@xiplink.com","subject":"Re: Pull is Mostly Evil","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2014-05-02T22:12:52Z","receivedAt":"2014-05-02T22:12:52Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Marc Branchaud\" \nSent: Friday, May 02, 2014 4:37 PM\n> (Apologies for not CCing all the folks who've participated in the \n> \"Pull is\n> Evil\" thread -- I couldn't find a good branch of that thread for this \n> message.)\n>\n> OK, so maybe \"git pull\" is just Mostly Evil. People seem to have \n> found many\n> different ways to make it work for them.\n>\n> But in reality \"git pull\" has become a chimera that confuses a large \n> number\n> of new users, and that experienced users either avoid entirely or \n> customize\n> to give them a convenient shorthand for working in their particular\n> environment. As a tool for new git users, it just doesn't seem to be\n> achieving its goals.\n>\n> I think the git project as a whole would benefit if it started to \n> treat \"git\n> pull\" as an advanced command, in the sense that it needs to be \n> configured by\n> an experienced user in order to make it correctly follow a project's\n> workflow. Once it's configured properly, \"git pull\" is a powerful \n> tool that\n> gives users an easy way to do complex things. In that sense, it may \n> be\n> appropriate for a project to tailor \"git pull\" as it likes, then teach \n> its\n> own users to use the command.\n>\n> However, when it comes to teaching people how to use git qua git, \"git \n> pull\"\n> should be the last thing they learn about, because it's only after you\n> understand various basic git concepts that you can configure \"git \n> pull\" to do\n> the right thing.\n>\n> To that end, I suggest that pull's default behaviour should be to do\n> *nothing*. It should just print out a message to the effect that it \n> hasn't\n> been configured, and that the user should run \"git help pull\" for \n> guidance.\n>\nI tend to agree.\nThe hard part is making sure folk have enough prior learning to make a \nchoice that their will fit their real needs.\n\n> It'll take quite a bit of time, but I think that if we change our \n> attitude\n> towards \"git pull\" and take this unconfigured-by-default approach, \n> then in a\n> few years the entire git ecosystem will be in a better place.\n>\n> M.\n> --\nPhilip\n"},{"id":"240589","messageId":"2F8B2EEED0594446A6FCF771BBEDFB56@PhilipOakley","threadId":"36567","inReplyTo":"5363ec734572a_70ef0f30cdc@nysa.notmuch","subject":"Re: Pull is Mostly Evil","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2014-05-02T22:34:18Z","receivedAt":"2014-05-02T22:34:18Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Felipe Contreras\" \nSent: Friday, May 02, 2014 8:05 PM\n> Philip Oakley wrote:\n>> From: \"David Kastrup\" \n>> > Marc Branchaud writes:\n>> >\n>> >> To that end, I suggest that pull's default behaviour should be to \n>> >> do\n>> >> *nothing*. It should just print out a message to the effect that \n>> >> it\n>> >> hasn't been configured, and that the user should run \"git help \n>> >> pull\"\n>> >> for guidance.\n>> >\n>> > Fetching is uncontentious, and I _think_ that fast-forwards are \n>> > pretty\n>> > uncontentious as well.\n>>\n>> While the fast forward is /pretty/ uncontentious, it still maybe\n>> contentious for some.\n>\n> So? No defaults can please absolutely everyone, the best anybody can \n> do\n> is try to please the majority of people, and merging fast-forwards \n> only\n> does that.\n\nThat assumes that doing something is better than doing nothing, which is \nappropriate when the costs on either side are roughly similar. However \nin this case, as we have essentially all agreed, there have been some \nbad down sides. In that case a precautionary principle is more \nappropriate where doing nothing (that is git pull does nothing until \nuser configured) is better.\n\nWhile a shift to merging fast-forwards would reduce the cost difference, \nthey have to be matched against the potential user confusions when \ncomparing to all the old web miss-instructions, hence my shift away from \ntrying to best guess a default, rather than simply suggest it as a \nsuitable user choice.\n>\n> -- \n> Felipe Contreras\n> --\nPhilip \n"},{"id":"240590","messageId":"20140502223612.GA11374@sigill.intra.peff.net","threadId":"36567","inReplyTo":"536414352fa24_1976139f2f0f9@nysa.notmuch","subject":"Re: Pull is Mostly Evil","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-05-02T22:36:13Z","receivedAt":"2014-05-02T22:36:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 02, 2014 at 04:55:01PM -0500, Felipe Contreras wrote:\n\n> They can do:\n> \n> % git pull origin master\n> \n> That shouldn't revese the bases.\n\nThen they have to remember to do that every time, no? That seems a\nlittle error-prone versus setting a config option.\n\n> > Such users are going to run \"git pull origin master\" or just \"git pull\"\n> > to get that merge.\n> \n> I'd say the vast majority of users running \"git pull\" want the parents\n> reversed, the minority that doesn't can switch to \"git pull origin\n> master\" (or add a configuration).\n\nI'm not sure I agree, but I don't think either of us has actual data.\n\n> Most likely the consensus and the proposals will be ignored and nothing\n> will change as usual, but that's a different thing.\n\nIs it truly necessary to make sniping comments like this at the end of\neach email? It _is_ being discussed right now, and these comments do\nnothing except irritate your readers. Please stop.\n\n-Peff\n"},{"id":"240593","messageId":"20140502225342.GQ9218@google.com","threadId":"36567","inReplyTo":"2F8B2EEED0594446A6FCF771BBEDFB56@PhilipOakley","subject":"Re: Pull is Mostly Evil","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-05-02T22:53:42Z","receivedAt":"2014-05-02T22:53:42Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nPhilip Oakley wrote:\n\n> That assumes that [git pull] doing something is better than doing nothing,\n> which is appropriate when the costs on either side are roughly\n> similar.\n\nI think the conversation's going around in circles.\n\nPotential next steps:\n\n a. Documentation or test patch illustrating desired behavior\n\n b. More traditional formal design doc explaining desired behavior and\n the thinking behind it (\"problem\", \"overview of solution\",\n \"alternatives rejected\", \"complications\", \"example\", \"open\n questions\").\n\n c. Implementation patch\n\n d. Someone takes an existing patch and figures out the next step\n toward getting it ready for application.\n\nMy preference is for (a), I guess.\n\nThe point being that something more concrete (code or a design doc)\nmakes it easier to avoid talking past each other. And having\nsomething concrete to edit makes the stakes clearer so people can make\nit incrementally better without being distracted by unimportant parts.\n\nThanks and hope that helps,\nJonathan\n"},{"id":"240598","messageId":"536428f7796e0_200c12912f03@nysa.notmuch","threadId":"36567","inReplyTo":"2F8B2EEED0594446A6FCF771BBEDFB56@PhilipOakley","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-02T23:23:35Z","receivedAt":"2014-05-02T23:23:35Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philip Oakley wrote:\n> From: \"Felipe Contreras\" \n> > So? No defaults can please absolutely everyone, the best anybody can\n> > do is try to please the majority of people, and merging\n> > fast-forwards only does that.\n> \n> That assumes that doing something is better than doing nothing,\n\nWhen doing something is better for the vast majority of people, that's\nwhat should be done by default, unless the results are catastrophic for\nthe minority.\n\nSince doing something is not catastrophic to the minority, it follows\nthat the default should be to do something.\n\nIt's a simple as that.\n\n-- \nFelipe Contreras\n"},{"id":"240599","messageId":"536429e97cf5a_200c12912f094@nysa.notmuch","threadId":"36567","inReplyTo":"20140502223612.GA11374@sigill.intra.peff.net","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-02T23:27:37Z","receivedAt":"2014-05-02T23:27:37Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Fri, May 02, 2014 at 04:55:01PM -0500, Felipe Contreras wrote:\n> \n> > They can do:\n> > \n> > % git pull origin master\n> > \n> > That shouldn't revese the bases.\n> \n> Then they have to remember to do that every time, no? That seems a\n> little error-prone versus setting a config option.\n\nYes. However, since not many people do this, and they don't do it that\noften that's not a big deal.\n\nIt's much more important to fix the issue the vast majority of users\nface constantly.\n\n> > > Such users are going to run \"git pull origin master\" or just \"git pull\"\n> > > to get that merge.\n> > \n> > I'd say the vast majority of users running \"git pull\" want the parents\n> > reversed, the minority that doesn't can switch to \"git pull origin\n> > master\" (or add a configuration).\n> \n> I'm not sure I agree, but I don't think either of us has actual data.\n\nDo you want me to go dig in the mailing list and point you to the\nendless discussions?\n\nI assure you, if this is not changed, we will have this discussion\nagain.\n\n> > Most likely the consensus and the proposals will be ignored and nothing\n> > will change as usual, but that's a different thing.\n> \n> Is it truly necessary to make sniping comments like this at the end of\n> each email? It _is_ being discussed right now, and these comments do\n> nothing except irritate your readers. Please stop.\n\nAnd it has been discussed before. If history is any indication, it will\nbe discussed again.\n\n-- \nFelipe Contreras\n"},{"id":"240604","messageId":"87wqe3wqp0.fsf@fencepost.gnu.org","threadId":"36567","inReplyTo":"20140502214817.GA10801@sigill.intra.peff.net","subject":"Re: Pull is Mostly Evil","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-03T02:18:03Z","receivedAt":"2014-05-03T02:18:03Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jeff King writes:\n\n> On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote:\n>\n>> Junio C Hamano wrote:\n>> > If we step back a bit, because we are forcing him to differentiate\n>> > these two pulls in his mental model anyway, perhaps it may help\n>> > people (both new and old) if we had a new command to make the\n>> > distinction stand out more. What if the command sequence were like\n>> > this instead?\n>> > \n>> > $ git checkout maint\n>> > $ git update [ origin maint ]\n>> > \n>> > $ git pull [--no-ff] developer-remote topic-branch\n>> > $ git push [ origin maint ]\n>> > \n>> > where the new command 'update' enforces the '--ff-only' update. And\n>> > then we would stop telling \"'git pull' first\" when a push does not\n>> > fast-forward.\n>> \n>> In addition to barf when it's not a fast-forward, such command can\n>> switch the parents, so it appears 'maint' was merged to 'origin/maint'.\n>> Many people have complained about this order.\n>\n> I realize this has veered off into talking about an \"update\" command,\n> and not necessarily \"pull\", but since there a lot of proposals floating\n> around, I wanted to make one point: if we are going to do such a switch,\n> let's please make it something the user explicitly turns on.\n\nA safety catch defaulting to a factory position of \"off\" is not going to\nstop inexperienced people from shooting themselves in the foot.\n\n-- \nDavid Kastrup\n"},{"id":"240615","messageId":"5364A143.1060404@bbn.com","threadId":"36567","inReplyTo":"xmqqoazgaw0y.fsf@gitster.dls.corp.google.com","subject":"Re: Pull is Mostly Evil","fromName":"Richard Hansen","fromEmail":"rhansen@bbn.com","sentAt":"2014-05-03T07:56:51Z","receivedAt":"2014-05-03T07:56:51Z","isPatch":false,"sender":{"key":"rhansen@rhansen.org","avatar":null},"body":"On 2014-05-02 14:13, Junio C Hamano wrote:\n> Stepping back even further, and thinking what is different between\n> these two pulls, we notice that the first one is pulling from the\n> place we push back to.\n\nI think the fundamental difference is in the relationship between the\nlocal and the remote branch (which branch derives from the other).\nThe relationship between the branches determines what the user wants\nfrom 'git pull'.\n\nIn my experience 'git pull' is mostly (only?) used for the following\nthree tasks:\n\n 1. update a local branch to incorporate the latest upstream changes\n\n In this case, the local branch (master) is a derivative of the\n upstream branch (origin/master). The user wants all of the\n commits in the remote branch to be in the local branch. And the\n user would like the local changes, if any, to descend from the tip\n of the remote branch.\n\n For this case, 'git pull --ff-only' followed by 'git rebase -p'\n works well, as does 'git pull --rebase=preserve' if the user is\n comfortable rebasing without reviewing the incoming commits first.\n A plain 'git pull' or 'git pull --ff' is suboptimal due to the\n awkward backwards-parents merge commit.\n\n 2. update a published feature branch with the latest changes from its\n parent branch\n\n In this case, the local branch (foo) is a derivative of the\n upstream branch (origin/foo) which is itself a derivative of\n another branch (origin/master). All commits in origin/master\n should be in origin/foo, and ideally all commits unique to\n origin/foo would descend from the tip of origin/master.\n\n The relationship between origin/foo and origin/master is similar\n to the relationship between master and origin/master in case #1\n above, but rebase is frowned upon because the feature branch has\n been shared with other developers (and the shared repository might\n reject non-ff updates).\n\n This case is sort-of like case #1 above (updating) and sort-of\n like case #3 below (integrating).\n\n For this case, after the local branch foo is updated (case #1\n above), 'git pull --ff origin master' or 'git fetch --all && git\n merge --ff origin/master' work well to update origin/foo.\n\n 3. integrate a more-or-less complete feature/fix back into the line\n of development it forked off of\n\n In this case the local branch is a primary line of development and\n the remote branch contains the derivative work. Think Linus\n pulling in contributions. Different situations will call for\n different ways to handle this case, but most will probably want\n some or all of:\n\n * rebase the remote commits onto local HEAD\n * merge into local HEAD so that the first parent (if a real merge\n and not a ff) is the previous version of the main line of\n development and the second parent is the derivative work\n * merge --no-ff so that:\n - the merge can serve as a cover letter (who reviewed it,\n which bug reports were fixed, where the changes came from,\n etc.)\n - the commits that compose the new topic are grouped together\n - the first-parent path represents a series of completed tasks\n\n (I prefer to do all three, although I may skip the rebase if the\n commits came from another public repository so as to not annoy\n users of that downstream repository.)\n\n For this case, 'git pull --no-ff' is better than 'git pull --ff'\n (for the reasons listed above), but perhaps something more\n elaborate would be ideal (e.g., rebase there onto here, then merge\n --no-ff).\n\nThese three usage patterns are at odds; it's hard to change the\ndefault behavior of 'git pull' to favor one usage case without harming\nanother. Perhaps this is why there's so much disagreement about what\n'git pull' should do.\n\nI see a few ways to improve the situation:\n\n 1. Add one or two new commands to split up how the three cases are\n handled. For example:\n\n * Add a new 'git update' command that is friendly for case\n #1. Update tutorials to recommend 'git update' instead of\n 'git pull'. It would behave like 'git pull --ff-only' by\n default.\n\n It could behave like 'git pull --rebase[=preserve]' instead,\n but this has a few downsides:\n - It doesn't give the user an opportunity to review the\n incoming commits before rebasing (e.g., to see what sort of\n conflicts to expect).\n - It subjects new users to that scary rebase thing before\n they are prepared to handle it.\n - The branch to be updated must be checked out. If 'git\n update' used --ff-only, then 'git update --all' could\n fast-forward all local branches to their configured\n upstreams when possible. (How cool would that be?)\n\n * Leave 'git pull' and 'git pull $remote [$refspec]' alone --\n the current defaults are acceptable (though maybe not ideal)\n for cases #2 and #3.\n\n Another example:\n\n * Add a new 'git integrate' command to handle case #3. Ideally\n it would be configurable enough to work with various\n workflows. It would behave like 'git pull --no-ff' by\n default.\n\n * Change plain 'git pull' to assume case #1 and default to\n --ff-only. It could default to --rebase[=preserve] instead,\n but that has the same downsides as those listed for 'git\n update' above.\n\n * Have 'git pull $remote [$refspec]' also default to merge\n --ff-only. It could assume case #2 and default to --ff, but\n that would cause 'git pull' to have different behaviors\n depending on how it is invoked. That might be too confusing\n to users. If 'git pull origin master' errors out due to\n non-ff, it's easy enough for users to manually run 'git merge\n origin/master'. Alternatively users could use 'git integrate\n origin master', so long as it does not rebase by default.\n Thus, I don't think that defaulting to --ff-only (when the\n remote is specified) would be a huge loss.\n\n 2. Teach 'git pull' to have different defaults depending on how it\n is invoked:\n\n * If plain 'git pull', assume case #1 above and default to merge\n --ff-only.\n * If 'git pull $configured_remote_name [$refspec]', assume case\n #2 and default to merge --ff.\n * If 'git pull $url [$refspec]', assume case #3 and default to\n merge --no-ff.\n\n I'm not a fan of this approach -- it seems like it would be a\n huge source of confusion for users.\n\n 3. Add some branch metadata to automatically figure out branch\n relationships, then adjust the default behavior of 'git pull'\n according to that metadata. This seems like a complicated and\n disruptive change, but it could have other benefits.\n\nOf these options, I prefer adding a new 'git integrate' command and\nchanging 'git pull' (and 'git pull $remote [$refspec]') to default to\n--ff-only.\n\n-Richard\n"},{"id":"240616","messageId":"87iopnwa2i.fsf@fencepost.gnu.org","threadId":"36567","inReplyTo":"5364A143.1060404@bbn.com","subject":"Re: Pull is Mostly Evil","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-03T08:17:09Z","receivedAt":"2014-05-03T08:17:09Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Richard Hansen writes:\n\n> These three usage patterns are at odds; it's hard to change the\n> default behavior of 'git pull' to favor one usage case without harming\n> another. Perhaps this is why there's so much disagreement about what\n> 'git pull' should do.\n\nShould a screwdriver be turning clockwise or counterclockwise by\ndefault? There are valid arguments for either.\n\n-- \nDavid Kastrup\n"},{"id":"240619","messageId":"5364b11b4db8d_1996f531068@nysa.notmuch","threadId":"36567","inReplyTo":"87iopnwa2i.fsf@fencepost.gnu.org","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-03T09:04:27Z","receivedAt":"2014-05-03T09:04:27Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Kastrup wrote:\n> Richard Hansen writes:\n> \n> > These three usage patterns are at odds; it's hard to change the\n> > default behavior of 'git pull' to favor one usage case without\n> > harming another. Perhaps this is why there's so much disagreement\n> > about what 'git pull' should do.\n> \n> Should a screwdriver be turning clockwise or counterclockwise by\n> default? There are valid arguments for either.\n\nIf you don't have anything to contribute don't disturb the people that\nactually care and are trying to improve Git. Thanks.\n\n-- \nFelipe Contreras\n"},{"id":"240620","messageId":"5364b62d5fb7b_ac68dd30816@nysa.notmuch","threadId":"36567","inReplyTo":"5364A143.1060404@bbn.com","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-03T09:26:05Z","receivedAt":"2014-05-03T09:26:05Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Richard Hansen wrote:\n\n> I think the fundamental difference is in the relationship between the\n> local and the remote branch (which branch derives from the other).\n> The relationship between the branches determines what the user wants\n> from 'git pull'.\n> \n> In my experience 'git pull' is mostly (only?) used for the following\n> three tasks:\n\nI agree.\n\n> 1. update a local branch to incorporate the latest upstream changes\n> \n> In this case, the local branch (master) is a derivative of the\n> upstream branch (origin/master). The user wants all of the\n> commits in the remote branch to be in the local branch. And the\n> user would like the local changes, if any, to descend from the tip\n> of the remote branch.\n\nMy current propsal of making `git pull` by default do --ff-only would\nsolve this. In addition I think by default 'master' should be merged to\n'origin/master', if say --merge is given.\n\n> For this case, 'git pull --ff-only' followed by 'git rebase -p'\n> works well, as does 'git pull --rebase=preserve' if the user is\n> comfortable rebasing without reviewing the incoming commits first.\n\nI suppose you mean a `git rebase -p` if the `git pull --ff-only` failed.\nThis might be OK on most projects, but not all.\n\nWhat happens after a `git pull --ff-only` fails should be totally\nup to the user.\n\n> 2. update a published feature branch with the latest changes from its\n> parent branch\n> \n> In this case, the local branch (foo) is a derivative of the\n> upstream branch (origin/foo) which is itself a derivative of\n> another branch (origin/master). All commits in origin/master\n> should be in origin/foo, and ideally all commits unique to\n> origin/foo would descend from the tip of origin/master.\n\nI don't understand why are you tainting the example with 'origin/foo',\n'foo' and 'origin/master' are enough for this example. In fact, the\nmention of 'origin/master' made it wrong: after the pull not all the\ncommits of origin/master would be in origin/foo, you need a push for\nthat. We have enough in our plate to taint this with yet another branch\nand push.\n\nFor this case `git pull origin master` already work correctly for most\nprojects. We probably shouldn't change that.\n\n> 3. integrate a more-or-less complete feature/fix back into the line\n> of development it forked off of\n> \n> In this case the local branch is a primary line of development and\n> the remote branch contains the derivative work. Think Linus\n> pulling in contributions. Different situations will call for\n> different ways to handle this case, but most will probably want\n> some or all of:\n> \n> * rebase the remote commits onto local HEAD\n\nNo. Most people will merge the remote branch as it is. There's no reason\nto rebase, specially if you are creating a merge commit.\n\n> * merge into local HEAD so that the first parent (if a real merge\n> and not a ff) is the previous version of the main line of\n> development and the second parent is the derivative work\n> * merge --no-ff so that:\n> - the merge can serve as a cover letter (who reviewed it,\n> which bug reports were fixed, where the changes came from,\n> etc.)\n> - the commits that compose the new topic are grouped together\n> - the first-parent path represents a series of completed tasks\n\nIt is very rare that an integrator is even able to do a fast-forward\nmerge anyway. So being explicit about --no-ff might better, but it would\nhardly make a difference. Either way, a good integrator would configure\npull.ff = false.\n\nI'd say `git pull origin master` already works fine for this case.\n\n-- \nFelipe Contreras\n"},{"id":"240621","messageId":"87eh0bw5gh.fsf@fencepost.gnu.org","threadId":"36567","inReplyTo":"5364b11b4db8d_1996f531068@nysa.notmuch","subject":"Re: Pull is Mostly Evil","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-03T09:56:46Z","receivedAt":"2014-05-03T09:56:46Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Felipe Contreras writes:\n\n> David Kastrup wrote:\n>> Richard Hansen writes:\n>> \n>> > These three usage patterns are at odds; it's hard to change the\n>> > default behavior of 'git pull' to favor one usage case without\n>> > harming another. Perhaps this is why there's so much disagreement\n>> > about what 'git pull' should do.\n>> \n>> Should a screwdriver be turning clockwise or counterclockwise by\n>> default? There are valid arguments for either.\n>\n> If you don't have anything to contribute don't disturb the people that\n> actually care and are trying to improve Git. Thanks.\n\nNo need to expand on the welcoming atmosphere here. My heinous plot to\nsubvert the quality of Git has already been thwarted by making sure that\nits \"meritocracy\" continues relying only on input from those with an\nindependent income. I'm just sticking around until my current\ncontributions move into master so that I can summarize the resulting\nlow-hanging fruit that the meritorious can then pick at great fanfare.\n\nThe sooner my work moves from pu into master, the sooner y'all be rid of\nme.\n\n-- \nDavid Kastrup\n"},{"id":"240622","messageId":"CAEBDL5USVuFDXQk7Cb9cJ8Lm4RJNeJB0DwZBCB1cXmkroD8w3g@mail.gmail.com","threadId":"36567","inReplyTo":"xmqqoazgaw0y.fsf@gitster.dls.corp.google.com","subject":"Re: Pull is Mostly Evil","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2014-05-03T10:00:44Z","receivedAt":"2014-05-03T10:00:44Z","isPatch":false,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Fri, May 2, 2014 at 2:13 PM, Junio C Hamano wrote:\n[snip]\n> Your earlier long-hand, together with the two examples that pulls\n> into the same \"maint\" branch Brian gave us, may give us a better\n> starting points to think about a saner way.\n>\n> To me, the problem sounds like:\n>\n> Tutorials of Git often says \"use 'git pull' to catch up your\n> branch with your upstream work and then 'git push' back\" (and\n> worse yet, 'git push' that does not fast-forward suggests doing\n> so), but 'git pull' that creates a merge in a wrong direction is\n> not the right thing for many people.\n\nYes, that's a good portion of the problem.\n\n> And proposed solutions range from \"let's write 'pull' off as a\n> failed experiment\" to \"let's forbid any merge made by use of 'pull'\n> by default, because it is likely that merge may be in reverse\".\n\nFWIW, at my company, we took another approach. We introduced a `git\nffwd` command that fetches from all remotes, and fast-forwards all\nyour local branches that are tracking a remote, and everyone on the\nteam uses it all the time. It should be said this team also likes to\nuse Git bare-metal, because they like knowing how things work\nout-of-the-box. But they all use the command because it's so\nconvenient.\n\nI had started making a C version a while back, but never completed it.\n I could take a stab at doing so again, if there's interest.\n\n-John\n"},{"id":"240624","messageId":"8F49068316F64566954C5D037C512704@PhilipOakley","threadId":"36567","inReplyTo":"536428f7796e0_200c12912f03@nysa.notmuch","subject":"Re: Pull is Mostly Evil","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2014-05-03T11:24:24Z","receivedAt":"2014-05-03T11:24:24Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Felipe Contreras\" \nSent: Saturday, May 03, 2014 12:23 AM\n> Philip Oakley wrote:\n>> From: \"Felipe Contreras\" \n>> > So? No defaults can please absolutely everyone, the best anybody \n>> > can\n>> > do is try to please the majority of people, and merging\n>> > fast-forwards only does that.\n>>\n>> That assumes that doing something is better than doing nothing,\n>\n> When doing something is better for the vast majority of people, that's\n> what should be done by default, unless the results are catastrophic \n> for\n> the minority.\n>\n> Since doing something is not catastrophic to the minority, it follows\n> that the default should be to do something.\n>\nThat 'Since' and 'it follows' are where we have a diverging \nunderstanding about the solution approach...\n\n> It's a simple as that.\n\n... which makes it not quite as simple as that ;-) [evidence: the \nongoing dialog among all and sundry]\n>\n> -- \n> Felipe Contreras\n> --\n\nPhilip \n"},{"id":"240625","messageId":"5364d3528eb93_14419272f03@nysa.notmuch","threadId":"36567","inReplyTo":"8F49068316F64566954C5D037C512704@PhilipOakley","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-03T11:30:26Z","receivedAt":"2014-05-03T11:30:26Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philip Oakley wrote:\n> From: \"Felipe Contreras\" \n> > When doing something is better for the vast majority of people, that's\n> > what should be done by default, unless the results are catastrophic \n> > for\n> > the minority.\n> >\n> > Since doing something is not catastrophic to the minority, it follows\n> > that the default should be to do something.\n\n> > It's a simple as that.\n> \n> ... which makes it not quite as simple as that ;-) [evidence: the \n> ongoing dialog among all and sundry]\n\nThe dialog is not simple becuase it's not easy to make `git pull` do the\nsensible thing. That doesn't mean `git pull` should do *nothing*, that\ndoesn't follow from the argument above.\n\n-- \nFelipe Contreras\n"},{"id":"240646","messageId":"CFC38D3E32F9460685EFFD76228E4E21@PhilipOakley","threadId":"36567","inReplyTo":"20140502225342.GQ9218@google.com","subject":"Re: Pull is Mostly Evil","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2014-05-03T20:24:44Z","receivedAt":"2014-05-03T20:24:44Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jonathan Nieder\" \nSent: Friday, May 02, 2014 11:53 PM\n> Hi,\n>\n> Philip Oakley wrote:\n>\n>> That assumes that [git pull] doing something is better than doing\n>> nothing,\n>> which is appropriate when the costs on either side are roughly\n>> similar.\n>\n> I think the conversation's going around in circles.\n\nI agree it's going around, but it's a non-exact recurrence. Issues are\nbeing surfaced.\n>\n> Potential next steps:\n>\n> a. Documentation or test patch illustrating desired behavior\n>\n> b. More traditional formal design doc explaining desired behavior and\n> the thinking behind it (\"problem\", \"overview of solution\",\n> \"alternatives rejected\", \"complications\", \"example\", \"open\n> questions\").\n>\n> c. Implementation patch\n>\n> d. Someone takes an existing patch and figures out the next step\n> toward getting it ready for application.\n>\n> My preference is for (a), I guess.\n\nI disagree about the leap to the presentation & discussion of a\n'solution' in these awkward scenarios (the old joke about \"if I were you\nI wouldn't start from here\", when asking for directions tends to apply).\nThis is the same point made by Brooks in the 'Mythical Man Month'. A\nleap to code is no guarantee of success.\n\n>\n> The point being that something more concrete (code or a design doc)\n> makes it easier to avoid talking past each other. And having\n> something concrete to edit makes the stakes clearer so people can make\n> it incrementally better without being distracted by unimportant parts.\n\nWe've had Junio's training wheel, and now Filipe's n'th attempt at code\nexamples, so my bad code wouldn't help ;-). As a systems engineer I've\nseen these confusions quite a few times in different guises.\n\nI tend to fall back to P Checkland's \"Systems Thinking, Systems\nPractice\" model of the various processes that have to go on [1] to\nimprove the situation (note he doesn't expect a solved solution in most\ncases, just an improvement in the situation). At the moment most of the\ndiscussion is in the \"unstructured\" parts of the processes. He also\nidentifies 6 elements 'CATWOE' [2] that need to be considered when\nstudying these problems.\n\nMost of the discussion/arguments here are about the different\n'Weltanshaung's\" (world views) of the contributors.\n\nIn terms of the new user pull problem, what needs to be modeled is the\nnew user's and their weltanshaung, not how we ('experienced' users?)\nmight 'solve' the problem.\n\nThe pull problem is, I believe part of the bigger problem of the\nmind-set shift required for the transition to a DVCS for most new users.\nGit has grown organically, so still has some soft (unclear) edges, which\nprobably needs more than just a transition plan for Filipe's pull\nchanges, and its choice of the final default (or lack of).\n\nFor example, if users aren't understanding the differences between\nremote branches, remote tracking branches, and branches, which is part\nof the pull problem; have we made it easy for them to understand? [They\nalready have to comprehend the 'staging' concept, so are already\ncognitively fully loaded].\n\nFor the branch type example, some cleaner naming may help, such as:\n'remote branch', 'Tracking branch', and '(local) branch', which excludes\nthe noiseword 'remote' from 'Tracking branches' (my deliberate 'T'\nemphasis). Though that does still leave the confusion between remote\nservers and remote repos, where the latter may actually be local, and if\na file path, be the local '.' repo itself!\n\n>\n> Thanks and hope that helps,\n\nSorry if this went off at a tangent, but I believe it's important to get\nto the bottom of the new user problems, which are deeper than just a few \ncommand defaults.\n\n> Jonathan\n> --\n\nPhilip\n--\n[1]\nhttp://40qx6d15vq6j25i83v3ks8nxfux.wpengine.netdna-cdn.com/files/2012/08/seven-steps2.gif\nor http://portals.wi.wur.nl/spicad/?Soft_Systems_Methodology Checkland's\n7 Steps.\n\n[2] CATWOE: customers, actors, transformation, weltanshaung, owners,\nenvironment.\n"},{"id":"240648","messageId":"5365691C.1010208@bbn.com","threadId":"36567","inReplyTo":"5364b62d5fb7b_ac68dd30816@nysa.notmuch","subject":"Re: Pull is Mostly Evil","fromName":"Richard Hansen","fromEmail":"rhansen@bbn.com","sentAt":"2014-05-03T22:09:32Z","receivedAt":"2014-05-03T22:09:32Z","isPatch":false,"sender":{"key":"rhansen@rhansen.org","avatar":null},"body":"On 2014-05-03 05:26, Felipe Contreras wrote:\n> Richard Hansen wrote:\n> \n>> I think the fundamental difference is in the relationship between the\n>> local and the remote branch (which branch derives from the other).\n>> The relationship between the branches determines what the user wants\n>> from 'git pull'.\n>>\n>> In my experience 'git pull' is mostly (only?) used for the following\n>> three tasks:\n> \n> I agree.\n> \n>> 1. update a local branch to incorporate the latest upstream changes\n>>\n>> In this case, the local branch (master) is a derivative of the\n>> upstream branch (origin/master). The user wants all of the\n>> commits in the remote branch to be in the local branch. And the\n>> user would like the local changes, if any, to descend from the tip\n>> of the remote branch.\n> \n> My current propsal of making `git pull` by default do --ff-only would\n> solve this.\n\nIt would go a long way toward improving the situation, yes.\n\n> In addition I think by default 'master' should be merged to\n> 'origin/master', if say --merge is given.\n\nThis would break cases #2 and #3. (With cases #2 and #3 you want the\nfetched branch to be the second parent, not the first.)\n\nOr are you proposing that pull --merge should reverse the parents if and\nonly if the remote ref is @{u}?\n\n> \n>> For this case, 'git pull --ff-only' followed by 'git rebase -p'\n>> works well, as does 'git pull --rebase=preserve' if the user is\n>> comfortable rebasing without reviewing the incoming commits first.\n> \n> I suppose you mean a `git rebase -p` if the `git pull --ff-only` failed.\n\nYes.\n\n> This might be OK on most projects, but not all.\n\nThe rebase only affects the local repository (the commits haven't been\npushed yet or else they'd be in @{u} already), so I'd say it's more of\nan individual developer decision than a project decision.\n\nIn my opinion rebase would be the best option here, but if the project\nis OK with developers pushing merge or merge-there commits and the\ndeveloper isn't yet comfortable with rebasing, then merge is also an\nacceptable option.\n\n> \n> What happens after a `git pull --ff-only` fails should be totally\n> up to the user.\n\nI tend to agree, mostly because I want users to have an opportunity to\nreview incoming commits before action is taken. Also, though rebasing\nwould yield the nicest history, some users aren't yet comfortable with\nrebase. If a project is OK with silly little merge commits from users\nthat aren't comfortable with rebase, then I don't want to force everyone\nto rebase by default.\n\nAs an added bonus: Defaulting to --ff-only makes it possible for 'git\npull --all' to fast-forward every local branch to their configured\nupstream, not just the currently checked-out branch. I think this would\nbe a huge usability win.\n\n> \n>> 2. update a published feature branch with the latest changes from its\n>> parent branch\n>>\n>> In this case, the local branch (foo) is a derivative of the\n>> upstream branch (origin/foo) which is itself a derivative of\n>> another branch (origin/master). All commits in origin/master\n>> should be in origin/foo, and ideally all commits unique to\n>> origin/foo would descend from the tip of origin/master.\n> \n> I don't understand why are you tainting the example with 'origin/foo',\n\nOriginally I didn't have this case in my list, but I added it after\nthinking about Peff's comment:\n\n On 2014-05-02 17:48, Jeff King wrote:\n > One common workflow for GitHub users is to back-merge master into a\n > topic, because they want the final \"integrated\" version on the topic\n > branch.\n\nThis almost but doesn't quite fit neatly into the other two cases. It's\nnot case #1 because the shared nature of origin/foo means that rebasing\norigin/foo onto origin/master is usually bad instead of usually good.\nIt's not case #3 because rebasing origin/master commits onto origin/foo\n(assuming that the user would usually want to rebase the topic branch\nwhen integrating) would definitely be bad.\n\n> 'foo' and 'origin/master' are enough for this example. In fact, the\n> mention of 'origin/master' made it wrong: after the pull not all the\n> commits of origin/master would be in origin/foo, you need a push for\n> that.\n\nThe push of foo to origin/foo was meant to be implied.\n\n> We have enough in our plate to taint this with yet another branch\n> and push.\n> \n> For this case `git pull origin master` already work correctly for most\n> projects.\n\nYes, it does.\n\n> We probably shouldn't change that.\n\nIf we change 'git pull' to default to --ff-only but let 'git pull\n$remote [$refspec]' continue to default to --ff then we have two\ndifferent behaviors depending on how 'git pull' is invoked. I'm worried\nthat this would trip up users. I'm not convinced that having two\ndifferent behaviors would be bad, but I'm not convinced that it would be\ngood either.\n\n> \n>> 3. integrate a more-or-less complete feature/fix back into the line\n>> of development it forked off of\n>>\n>> In this case the local branch is a primary line of development and\n>> the remote branch contains the derivative work. Think Linus\n>> pulling in contributions. Different situations will call for\n>> different ways to handle this case, but most will probably want\n>> some or all of:\n>>\n>> * rebase the remote commits onto local HEAD\n> \n> No. Most people will merge the remote branch as it is. There's no reason\n> to rebase, specially if you are creating a merge commit.\n\nI disagree. I prefer to rebase a topic branch before merging (no-ff) to\nthe main line of development for a couple of reasons:\n\n * It makes commits easier to review. For example, assume the\n following commit history:\n\n * merge topic-foo\n |\\\n | * merge master into topic-foo\n |/|\n * | tweak the behavior of Thing\n | |\n | * refactor Thing\n | |\n | * wrap long lines; no behavior changes\n |/\n * blah\n |\n ...\n\n In this case, the impact the \"refactor Thing\" and \"wrap long lines\"\n commits have on master can't be fully understood without also\n examining the presumed merge conflict resolution in the \"merge\n master into topic-foo\" commit. Merge commits are very hard to\n review, even if (especially if?) there are no conflicts.\n Developers can diff 'merge topic-foo' to its first parent, but then\n they'll see lots of noise caused by the \"wrap long lines\" commit.\n\n If the integrator rebases first, then the history looks like this:\n\n * merge topic-foo\n |\\\n | * refactor Thing\n | |\n | * wrap long lines; no behavior changes\n |/\n * tweak the behavior of Thing\n |\n * blah\n |\n ...\n\n Now the merge conflict resolution is integrated into the \"refactor\n Thing\" and \"wrap long lines\" commits, making them easier to review.\n\n * Rebasing makes the commit history pretty and easier to understand.\n Instead of this:\n\n * merge feature.xyz\n |\\\n | * xyz part 3/3\n | |\n | * merge master into feature.xyz\n |/|\n * | merge feature.foo\n |\\ \\\n | | * xyz part 2/3\n | * | foo part 2/2\n | * | foo part 1/2\n | | * xyz part 1/3\n |/ /\n | /\n |/\n * merge feature.bar\n |\\\n\n you get this:\n\n * merge feature.xyz\n |\\\n | * xyz part 3/3\n | * xyz part 2/3\n | * xyz part 1/3\n |/\n * merge feature.foo\n |\\\n | * foo part 2/2\n | * foo part 1/2\n |/\n * merge feature.bar\n |\\\n\n When there are regularly dozens of active branches at a time, this\n improved readability can be quite valuable.\n\n> \n>> * merge into local HEAD so that the first parent (if a real merge\n>> and not a ff) is the previous version of the main line of\n>> development and the second parent is the derivative work\n>> * merge --no-ff so that:\n>> - the merge can serve as a cover letter (who reviewed it,\n>> which bug reports were fixed, where the changes came from,\n>> etc.)\n>> - the commits that compose the new topic are grouped together\n>> - the first-parent path represents a series of completed tasks\n> \n> It is very rare that an integrator is even able to do a fast-forward\n> merge anyway.\n\nIt depends on the level of project activity. A project as active as the\nLinux kernel or Git will almost never have fast-forwards. But\noccasional contributions by random users to a small, simple project will\nlikely be fast-forwards.\n\n> So being explicit about --no-ff might better, but it would\n> hardly make a difference. Either way, a good integrator would configure\n> pull.ff = false.\n\nConfiguring pull.ff = false is OK if the integrator only integrates and\nonly uses one machine. But if the integrator also wants to develop in\nthe same repository, or if the integrator uses multiple machines to do\nthe integration work (e.g., office desktop and laptop), then setting\npull.ff may be less convenient, not more.\n\nMaybe it's OK to require integrators to get in the habit of typing 'git\npull --no-ff'. Presumably integrators are experienced Git users, so\nthey can create their own 'git integrate' alias if they don't want to\nhave to remember to type '--no-ff' all the time.\n\n> \n> I'd say `git pull origin master` already works fine for this case.\n\nIt does, but again preserving the current behavior would cause the\nbehavior of 'git pull origin master' to be inconsistent with the\nproposed ff-only default for a plain 'git pull'.\n\n-Richard\n"},{"id":"240657","messageId":"5365af33825c3_520db2b308bf@nysa.notmuch","threadId":"36567","inReplyTo":"5365691C.1010208@bbn.com","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-04T03:08:35Z","receivedAt":"2014-05-04T03:08:35Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Richard Hansen wrote:\n> On 2014-05-03 05:26, Felipe Contreras wrote:\n> > Richard Hansen wrote:\n> > \n> >> I think the fundamental difference is in the relationship between the\n> >> local and the remote branch (which branch derives from the other).\n> >> The relationship between the branches determines what the user wants\n> >> from 'git pull'.\n> >>\n> >> In my experience 'git pull' is mostly (only?) used for the following\n> >> three tasks:\n> > \n> > I agree.\n> > \n> >> 1. update a local branch to incorporate the latest upstream changes\n> >>\n> >> In this case, the local branch (master) is a derivative of the\n> >> upstream branch (origin/master). The user wants all of the\n> >> commits in the remote branch to be in the local branch. And the\n> >> user would like the local changes, if any, to descend from the tip\n> >> of the remote branch.\n> > \n> > My current propsal of making `git pull` by default do --ff-only would\n> > solve this.\n> \n> It would go a long way toward improving the situation, yes.\n> \n> > In addition I think by default 'master' should be merged to\n> > 'origin/master', if say --merge is given.\n> \n> This would break cases #2 and #3. (With cases #2 and #3 you want the\n> fetched branch to be the second parent, not the first.)\n> \n> Or are you proposing that pull --merge should reverse the parents if and\n> only if the remote ref is @{u}?\n\nOnly if no remote or branch are specified `git pull --merge`.\n\n> > \n> >> For this case, 'git pull --ff-only' followed by 'git rebase -p'\n> >> works well, as does 'git pull --rebase=preserve' if the user is\n> >> comfortable rebasing without reviewing the incoming commits first.\n> > \n> > I suppose you mean a `git rebase -p` if the `git pull --ff-only` failed.\n> \n> Yes.\n> \n> > This might be OK on most projects, but not all.\n> \n> The rebase only affects the local repository (the commits haven't been\n> pushed yet or else they'd be in @{u} already), so I'd say it's more of\n> an individual developer decision than a project decision.\n> \n> In my opinion rebase would be the best option here, but if the project\n> is OK with developers pushing merge or merge-there commits and the\n> developer isn't yet comfortable with rebasing, then merge is also an\n> acceptable option.\n\nPrecisely for that reason.\n\n> >> 2. update a published feature branch with the latest changes from its\n> >> parent branch\n\n> > We probably shouldn't change that.\n> \n> If we change 'git pull' to default to --ff-only but let 'git pull\n> $remote [$refspec]' continue to default to --ff then we have two\n> different behaviors depending on how 'git pull' is invoked. I'm worried\n> that this would trip up users. I'm not convinced that having two\n> different behaviors would be bad, but I'm not convinced that it would be\n> good either.\n\nIt is the only solution that has been proposed.\n\nMoreover, while it's a bit worrisome, it wouldn't create any actual\nproblems. Since `git pull $what` remains the same, there's no problems\nthere. The only change would be on `git pull`.\n\nSince most users are not going to do `git pull $what` therefore it would\nonly be a small subset of users that would notice the discrepancy\nbetween running with $what, or not. And the only discrepancy they could\nnotice is that when they run `git pull $what` they expect it to be\n--ff-only, or when the run `git pull` they don't. Only the former could\nbe an issue, but even then, it's highly unlikely that `git pull $what`\nwould ever be a fast-forward.\n\nSo althought conceptually it doesn't look clean, in reality there\nwouldn't be any problems.\n\n> >> 3. integrate a more-or-less complete feature/fix back into the line\n> >> of development it forked off of\n> >>\n> >> In this case the local branch is a primary line of development and\n> >> the remote branch contains the derivative work. Think Linus\n> >> pulling in contributions. Different situations will call for\n> >> different ways to handle this case, but most will probably want\n> >> some or all of:\n> >>\n> >> * rebase the remote commits onto local HEAD\n> > \n> > No. Most people will merge the remote branch as it is. There's no reason\n> > to rebase, specially if you are creating a merge commit.\n> \n> I disagree. I prefer to rebase a topic branch before merging (no-ff) to\n> the main line of development for a couple of reasons:\n\nWell that is *your* preference. Most people would prefer to preserve the\nhistory.\n\n> * It makes commits easier to review.\n\nThe review in the vast majority of cases happens *before* the\nintegration.\n\nAnd the problem comes when the integrator makes a mistake, which they\ninevitable do (we all do), then there's no history about how the\nconflict was resolved, and what whas the original patch.\n\nThat's why most people don't do this.\n\n> * Rebasing makes the commit history pretty and easier to understand.\n\nIt is more important to be able to track integration errors than to have\na pretty history. That is for most people.\n\nI like to have a pretty history for my own local branches, but once\nsomething gets integrated it's important to see who did exactly what\n(the integrator did the merge).\n> > It is very rare that an integrator is even able to do a fast-forward\n> > merge anyway.\n> \n> It depends on the level of project activity. A project as active as the\n> Linux kernel or Git will almost never have fast-forwards. But\n> occasional contributions by random users to a small, simple project will\n> likely be fast-forwards.\n\nAnd small simple projects don't care about such issues.\n\n> > So being explicit about --no-ff might better, but it would\n> > hardly make a difference. Either way, a good integrator would configure\n> > pull.ff = false.\n> \n> Configuring pull.ff = false is OK if the integrator only integrates and\n> only uses one machine. But if the integrator also wants to develop in\n> the same repository, or if the integrator uses multiple machines to do\n> the integration work (e.g., office desktop and laptop), then setting\n> pull.ff may be less convenient, not more.\n\nAny good integrator would find solutions for those problems easily.\n\nEither way I don't see any proposed solutions.\n\n> > I'd say `git pull origin master` already works fine for this case.\n> \n> It does, but again preserving the current behavior would cause the\n> behavior of 'git pull origin master' to be inconsistent with the\n> proposed ff-only default for a plain 'git pull'.\n\nYes, it doesn't look clean. But I don't see any proposed alternatives.\n\n-- \nFelipe Contreras\n"},{"id":"240658","messageId":"alpine.DEB.2.02.1405032129420.25156@nftneq.ynat.uz","threadId":"36567","inReplyTo":"87eh0bw5gh.fsf@fencepost.gnu.org","subject":"Re: Pull is Mostly Evil","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2014-05-04T04:30:54Z","receivedAt":"2014-05-04T04:30:54Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sat, 3 May 2014, David Kastrup wrote:\n\n> Felipe Contreras writes:\n>\n>> David Kastrup wrote:\n>>> Richard Hansen writes:\n>>>\n>>>> These three usage patterns are at odds; it's hard to change the\n>>>> default behavior of 'git pull' to favor one usage case without\n>>>> harming another. Perhaps this is why there's so much disagreement\n>>>> about what 'git pull' should do.\n>>>\n>>> Should a screwdriver be turning clockwise or counterclockwise by\n>>> default? There are valid arguments for either.\n>>\n>> If you don't have anything to contribute don't disturb the people that\n>> actually care and are trying to improve Git. Thanks.\n>\n> No need to expand on the welcoming atmosphere here.\n\nnote that this is one person taking the \"I don't see any commits from you so \nyour opinion doesn't count\" attitude.\n\nthe vast majority of people here do not take that attitude.\n\nDavid Lang\n\n> My heinous plot to\n> subvert the quality of Git has already been thwarted by making sure that\n> its \"meritocracy\" continues relying only on input from those with an\n> independent income. I'm just sticking around until my current\n> contributions move into master so that I can summarize the resulting\n> low-hanging fruit that the meritorious can then pick at great fanfare.\n>\n> The sooner my work moves from pu into master, the sooner y'all be rid of\n> me.\n>\n>"},{"id":"240659","messageId":"5365c45fd101d_6c25cd72ec2e@nysa.notmuch","threadId":"36567","inReplyTo":"alpine.DEB.2.02.1405032129420.25156@nftneq.ynat.uz","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-04T04:38:55Z","receivedAt":"2014-05-04T04:38:55Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"David Lang wrote:\n> note that this is one person taking the \"I don't see any commits from\n> you so your opinion doesn't count\" attitude.\n\nWrong. I said it doesn't count \"for the project\". Do you honestly\nbelieve Junio cares about what some random guy on the list thinks about\ndefault aliases? No.\n\nIf he doesn't care what literally everyone thinks about the name\n\"index\", why would he care about that random guy?\n\n> the vast majority of people here do not take that attitude.\n\nIt's actually the exact opposite. I don't care what is the track record\nof the people in the discussion. If their argument is good, their\nargument is good.\n\nIt's the others that focus on the carisma and credentials of the people\nin the discussion, rather than the arguments.\n\n-- \nFelipe Contreras\n"},{"id":"240663","messageId":"87wqe2ul4j.fsf@fencepost.gnu.org","threadId":"36567","inReplyTo":"5365c45fd101d_6c25cd72ec2e@nysa.notmuch","subject":"Re: Pull is Mostly Evil","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-04T06:13:32Z","receivedAt":"2014-05-04T06:13:32Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Felipe Contreras writes:\n\n> David Lang wrote:\n>> note that this is one person taking the \"I don't see any commits from\n>> you so your opinion doesn't count\" attitude.\n>\n> Wrong. I said it doesn't count \"for the project\".\n\nThere are a number of commits from me that actually count. A few old\ncore performance ones might have actually have affected my carbon\nfootprint noticeably. The one currently in pu will probably not be\ncalled often enough for that but will at least have practical\nconsequences.\n\n> Do you honestly believe Junio cares about what some random guy on the\n> list thinks about default aliases? No.\n\nPutting aside my code contributions: Git is a comparatively small\nproject, so if the main project you are working on with Git is Git, your\nexperience is limited. So yes, input from people who are _not_ heavy\nGit developers is important, since the heavy Git developers do not get\nto see the heavy Git use cases a lot.\n\n> It's actually the exact opposite. I don't care what is the track\n> record of the people in the discussion. If their argument is good,\n> their argument is good.\n\nMore like if they are around, they are worth getting plastered with your\nfrustration.\n\n> It's the others that focus on the carisma and credentials of the\n> people in the discussion, rather than the arguments.\n\nI think you are confusing inertia with resistance.\n\n-- \nDavid Kastrup\n"},{"id":"240669","messageId":"eae08db4-f59f-4237-8f04-ebf33dbf6f67@email.android.com","threadId":"36567","inReplyTo":"5365c45fd101d_6c25cd72ec2e@nysa.notmuch","subject":"Re: Pull is Mostly Evil","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-05-04T06:50:58Z","receivedAt":"2014-05-04T06:50:58Z","isPatch":false,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"Felipe Contreras wrote:\n>David Lang wrote:\n>> the vast majority of people here do not take that attitude.\n>\n>It's actually the exact opposite. I don't care what is the track record\n>of the people in the discussion.\n\nAh, yes, like that discussion we once had where you totally\ndidn't run `git log | grep James Denholm` at one point to demonstrate that I had not yet made any\ncontributions,instead of actually engaging in discussion. Oh,\nwait.\n\n>If their argument is good, their argument is good.\n\nThe problem, though, is that time and time again you've\nshown that you value your own arguments to the exclusion\nof all others. You can't tell if someone else's argument is\n good, because it runs against yours, and yours must be\nright because you hold it.\n\nRegards,\nJames Denholm.\n"},{"id":"240670","messageId":"87sioqugpg.fsf@fencepost.gnu.org","threadId":"36567","inReplyTo":"eae08db4-f59f-4237-8f04-ebf33dbf6f67@email.android.com","subject":"Re: Pull is Mostly Evil","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-04T07:48:59Z","receivedAt":"2014-05-04T07:48:59Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"James Denholm writes:\n\n> Felipe Contreras wrote:\n>>David Lang wrote:\n>>> the vast majority of people here do not take that attitude.\n>>\n>>It's actually the exact opposite. I don't care what is the track record\n>>of the people in the discussion.\n>\n> Ah, yes, like that discussion we once had where you totally\n> didn't run `git log | grep James Denholm` at one point to demonstrate\n> that I had not yet made any\n> contributions,instead of actually engaging in discussion. Oh,\n> wait.\n\nIt's called an \"ad hominem attack\", and it's a very common and very\neffective rhetorical device.\n\nCf\n\n\n> The problem, though, is that time and time again you've\n> shown that you value your own arguments to the exclusion\n> of all others. You can't tell if someone else's argument is\n> good, because it runs against yours, and yours must be\n> right because you hold it.\n\nIf he considered others capable of independent thought, would he call\nout their imperviousness to rhetorics as a deficiency?\n\n-- \nDavid Kastrup\n"},{"id":"240671","messageId":"5365F10C.6020604@bbn.com","threadId":"36567","inReplyTo":"5365af33825c3_520db2b308bf@nysa.notmuch","subject":"Re: Pull is Mostly Evil","fromName":"Richard Hansen","fromEmail":"rhansen@bbn.com","sentAt":"2014-05-04T07:49:32Z","receivedAt":"2014-05-04T07:49:32Z","isPatch":false,"sender":{"key":"rhansen@rhansen.org","avatar":null},"body":"On 2014-05-03 23:08, Felipe Contreras wrote:\n> Richard Hansen wrote:\n>> Or are you proposing that pull --merge should reverse the parents if and\n>> only if the remote ref is @{u}?\n> \n> Only if no remote or branch are specified `git pull --merge`.\n\nOK. Let me summarize to make sure I understand your full proposal:\n\n 1. if plain 'git pull', default to --ff-only\n 2. if 'git pull --merge', default to --ff. If the local branch can't\n be fast-forwarded to the upstream branch, then create a merge\n commit where the local branch is the *second* parent, not the first\n 3. if 'git pull $remote [$refspec]', default to --merge --ff. If the\n local branch can't be fast-forwarded to the remote branch, then\n create a merge commit where the remote branch is the second parent\n (the current behavior)\n\nIs that accurate?\n\n>> If we change 'git pull' to default to --ff-only but let 'git pull\n>> $remote [$refspec]' continue to default to --ff then we have two\n>> different behaviors depending on how 'git pull' is invoked. I'm worried\n>> that this would trip up users. I'm not convinced that having two\n>> different behaviors would be bad, but I'm not convinced that it would be\n>> good either.\n> \n> It is the only solution that has been proposed.\n\nIt's not the only proposal -- I proposed a few alternatives in my\nearlier email (though not in the form of code), and others have too. In\nparticular:\n\n * create a new 'git integrate' command/alias that behaves like 'git\n pull --no-ff'\n * change 'git pull' and 'git pull $remote [$refspec]' to do --ff-only\n by default\n\nAnother option that I just thought of: Instead of your proposed\npull.mode and branch..pullmode, add the following two sets of configs:\n\n * pull.updateMode, branch..pullUpdateMode:\n\n The default mode to use when running 'git pull' without naming a\n remote repository or when the named remote branch is @{u}. Valid\n options: ff-only (default), merge-ff, merge-ff-there, merge-no-ff,\n merge-no-ff-there, rebase, rebase-here, rebase-here-then-merge-no-ff\n\n * pull.integrateMode, branch..pullIntegrateMode:\n\n The default mode to use when running 'git pull $remote [$refspec]'\n when '$remote [$refspec]' is not @{u}. Valid options are the same\n as those for pull.updateMode. Default is merge-ff.\n\nThis gives the default split behavior as you propose, but the user can\nreconfigure to suit personal preference (and we can easily change the\ndefault for one or the other if there's too much outcry).\n\n> \n> Moreover, while it's a bit worrisome, it wouldn't create any actual\n> problems. Since `git pull $what` remains the same, there's no problems\n> there. The only change would be on `git pull`.\n> \n> Since most users are not going to do `git pull $what` therefore it would\n> only be a small subset of users that would notice the discrepancy\n> between running with $what, or not. And the only discrepancy they could\n> notice is that when they run `git pull $what` they expect it to be\n> --ff-only, or when the run `git pull` they don't. Only the former could\n> be an issue, but even then, it's highly unlikely that `git pull $what`\n> would ever be a fast-forward.\n> \n> So althought conceptually it doesn't look clean, in reality there\n> wouldn't be any problems.\n\nYes, it might not be a problem, but I'm still nervous. I'd need more\ninput (e.g., user survey, broad mailing list consensus, long beta test\nperiod, decree by a benevolent dictator) before I'd be comfortable with it.\n\n> \n>>>> 3. integrate a more-or-less complete feature/fix back into the line\n>>>> of development it forked off of\n>>>>\n>>>> In this case the local branch is a primary line of development and\n>>>> the remote branch contains the derivative work. Think Linus\n>>>> pulling in contributions. Different situations will call for\n>>>> different ways to handle this case, but most will probably want\n>>>> some or all of:\n>>>>\n>>>> * rebase the remote commits onto local HEAD\n>>>\n>>> No. Most people will merge the remote branch as it is. There's no reason\n>>> to rebase, specially if you are creating a merge commit.\n>>\n>> I disagree. I prefer to rebase a topic branch before merging (no-ff) to\n>> the main line of development for a couple of reasons:\n> \n> Well that is *your* preference. Most people would prefer to preserve the\n> history.\n\nProbably. My point is that the behavior should be configurable, and I'd\nlike that particular behavior to be one of the options (but not the\ndefault -- that wouldn't be appropriate).\n\n> \n>> * It makes commits easier to review.\n> \n> The review in the vast majority of cases happens *before* the\n> integration.\n\nTrue, although even when review happens before integration there is\nvalue in making code archeology easier.\n\n> \n> And the problem comes when the integrator makes a mistake, which they\n> inevitable do (we all do), then there's no history about how the\n> conflict was resolved, and what whas the original patch.\n\nGood point, although if I was the integrator and there was a\nparticularly hairy conflict I'd still rebase but ask the original\ncontributor to review the results before merging (or ask the contributor\nto rebase).\n\n-Richard\n"},{"id":"240676","messageId":"53660d8d74c68_1c89b0930c53@nysa.notmuch","threadId":"36567","inReplyTo":"eae08db4-f59f-4237-8f04-ebf33dbf6f67@email.android.com","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-04T09:51:09Z","receivedAt":"2014-05-04T09:51:09Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"James Denholm wrote:\n> Felipe Contreras wrote:\n> >David Lang wrote:\n> >> the vast majority of people here do not take that attitude.\n> >\n> >It's actually the exact opposite. I don't care what is the track record\n> >of the people in the discussion.\n> \n> Ah, yes, like that discussion we once had where you totally didn't run\n> `git log | grep James Denholm` at one point to demonstrate that I had\n> not yet made any contributions,instead of actually engaging in\n> discussion. Oh, wait.\n\nYou mean this thread[1] in which I sent 14 mails directly to you? Yeah,\nI din't engage in that discussion at all!\n\nAnd the point I was making is that if I manage to show the community was\nwrong in some thing (as you claimed), that community wouldn't include\nyou.\n\n> >If their argument is good, their argument is good.\n> \n> The problem, though, is that time and time again you've shown that you\n> value your own arguments to the exclusion of all others. You can't\n> tell if someone else's argument is good, because it runs against\n> yours, and yours must be right because you hold it.\n\nI can show you evidence of how that's a blatant lie. Just two days ago I\nchanged my mind because somebody provided a good argument.\n\nBut I'm not going to bother any more with you, you are just spreading\nlies and tainting the discussion.\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/247188/focus=247584\n\n-- \nFelipe Contreras\n"},{"id":"240679","messageId":"536613bd14e24_1c89b0930cac@nysa.notmuch","threadId":"36567","inReplyTo":"5365F10C.6020604@bbn.com","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-04T10:17:33Z","receivedAt":"2014-05-04T10:17:33Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Richard Hansen wrote:\n> On 2014-05-03 23:08, Felipe Contreras wrote:\n> > Richard Hansen wrote:\n> >> Or are you proposing that pull --merge should reverse the parents if and\n> >> only if the remote ref is @{u}?\n> > \n> > Only if no remote or branch are specified `git pull --merge`.\n> \n> OK. Let me summarize to make sure I understand your full proposal:\n> \n> 1. if plain 'git pull', default to --ff-only\n> 2. if 'git pull --merge', default to --ff. If the local branch can't\n> be fast-forwarded to the upstream branch, then create a merge\n> commit where the local branch is the *second* parent, not the first\n> 3. if 'git pull $remote [$refspec]', default to --merge --ff. If the\n> local branch can't be fast-forwarded to the remote branch, then\n> create a merge commit where the remote branch is the second parent\n> (the current behavior)\n> \n> Is that accurate?\n\nYes, that is accurate. Note that 3. is the current behavior.\n\n> >> If we change 'git pull' to default to --ff-only but let 'git pull\n> >> $remote [$refspec]' continue to default to --ff then we have two\n> >> different behaviors depending on how 'git pull' is invoked. I'm worried\n> >> that this would trip up users. I'm not convinced that having two\n> >> different behaviors would be bad, but I'm not convinced that it would be\n> >> good either.\n> > \n> > It is the only solution that has been proposed.\n> \n> It's not the only proposal -- I proposed a few alternatives in my\n> earlier email (though not in the form of code), and others have too. In\n> particular:\n> \n> * create a new 'git integrate' command/alias that behaves like 'git\n> pull --no-ff'\n\nYeah but that's for a different issue altogheter. I doesn't solve the\nproblems in 1. nor 2. nor 3.\n\n> * change 'git pull' and 'git pull $remote [$refspec]' to do --ff-only\n> by default\n> \n> Another option that I just thought of: Instead of your proposed\n> pull.mode and branch..pullmode, add the following two sets of configs:\n> \n> * pull.updateMode, branch..pullUpdateMode:\n> \n> The default mode to use when running 'git pull' without naming a\n> remote repository or when the named remote branch is @{u}. Valid\n> options: ff-only (default), merge-ff, merge-ff-there, merge-no-ff,\n> merge-no-ff-there, rebase, rebase-here, rebase-here-then-merge-no-ff\n\nThose are way too many options to be able to sensibly explain them.\n\n> * pull.integrateMode, branch..pullIntegrateMode:\n> \n> The default mode to use when running 'git pull $remote [$refspec]'\n> when '$remote [$refspec]' is not @{u}. Valid options are the same\n> as those for pull.updateMode. Default is merge-ff.\n> \n> This gives the default split behavior as you propose, but the user can\n> reconfigure to suit personal preference (and we can easily change the\n> default for one or the other if there's too much outcry).\n\nIf we reduce the number of options to begin with (more can be added\nlater), then it might make sense to have these two options.\n\nHowever, that doesn't change the proposal you described above (1. 2.\n3.).\n\n> > Moreover, while it's a bit worrisome, it wouldn't create any actual\n> > problems. Since `git pull $what` remains the same, there's no problems\n> > there. The only change would be on `git pull`.\n> > \n> > Since most users are not going to do `git pull $what` therefore it would\n> > only be a small subset of users that would notice the discrepancy\n> > between running with $what, or not. And the only discrepancy they could\n> > notice is that when they run `git pull $what` they expect it to be\n> > --ff-only, or when the run `git pull` they don't. Only the former could\n> > be an issue, but even then, it's highly unlikely that `git pull $what`\n> > would ever be a fast-forward.\n> > \n> > So althought conceptually it doesn't look clean, in reality there\n> > wouldn't be any problems.\n> \n> Yes, it might not be a problem, but I'm still nervous. I'd need more\n> input (e.g., user survey, broad mailing list consensus, long beta test\n> period, decree by a benevolent dictator) before I'd be comfortable with it.\n\nThe user surveys are not happening any more. The results were ignored by\nthe developers anyway.\n\nMailing list consensus might be possible, but that wouldn't tell us\nmuch.\n\nThere's something we can do, and let me clarify my proposal. What you\ndescribed above is what I think should happen eventually, however, we\ncan start by doing something like what my patch series is doing; issue a\nwarning that the merge is not fast-forward and things might change in\nthe future.\n\nIf people find this behavior confusing they will complain in the mailing\nlist. Although I suspect it would be for other reasons, not the 'git\npull'/'git pull $there' division. Either way we would see in the\ndiscussion.\n\n> >>>> 3. integrate a more-or-less complete feature/fix back into the line\n> >>>> of development it forked off of\n> >>>>\n> >>>> In this case the local branch is a primary line of development and\n> >>>> the remote branch contains the derivative work. Think Linus\n> >>>> pulling in contributions. Different situations will call for\n> >>>> different ways to handle this case, but most will probably want\n> >>>> some or all of:\n> >>>>\n> >>>> * rebase the remote commits onto local HEAD\n> >>>\n> >>> No. Most people will merge the remote branch as it is. There's no reason\n> >>> to rebase, specially if you are creating a merge commit.\n> >>\n> >> I disagree. I prefer to rebase a topic branch before merging (no-ff) to\n> >> the main line of development for a couple of reasons:\n> > \n> > Well that is *your* preference. Most people would prefer to preserve the\n> > history.\n> \n> Probably. My point is that the behavior should be configurable, and I'd\n> like that particular behavior to be one of the options (but not the\n> default -- that wouldn't be appropriate).\n\nAll right. But I'm a bit overwhelmed by all the things to keep in mind.\nDoes your proposed IntegradeMode/UpdateMode deal with this?\n\nI will try to gather a bunch of discussions and create a new thread to\nsummrize what is probably the best, and Intage/Update mode is as far as\nI'm willing to go into considering options.\n\n> >> * It makes commits easier to review.\n> > \n> > The review in the vast majority of cases happens *before* the\n> > integration.\n> \n> True, although even when review happens before integration there is\n> value in making code archeology easier.\n\nI think I explained below why \"code archeology\" is better served by\npreserving the history.\n\n> > And the problem comes when the integrator makes a mistake, which they\n> > inevitable do (we all do), then there's no history about how the\n> > conflict was resolved, and what whas the original patch.\n> \n> Good point, although if I was the integrator and there was a\n> particularly hairy conflict I'd still rebase but ask the original\n> contributor to review the results before merging (or ask the contributor\n> to rebase).\n\nSure, asking the contributor to rebase is best. However, sending the\nrebase results is not that useful; the contributor would like to see\nwhat actually changed so an interdiff might be more than enough. But\nthen that's basically the same as reviewing the merge commit.\n\nAnyway, I'll try to grab what I can from previous discussions (mainly\nabout switching the merge parents) and create a new thread with a\nsummary.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"240680","messageId":"2bbbfedd-b224-4ef0-a611-fe78d3446db8@email.android.com","threadId":"36567","inReplyTo":"53660d8d74c68_1c89b0930c53@nysa.notmuch","subject":"Re: Pull is Mostly Evil","fromName":"James Denholm","fromEmail":"nod.helm@gmail.com","sentAt":"2014-05-04T10:37:19Z","receivedAt":"2014-05-04T10:37:19Z","isPatch":false,"sender":{"key":"nod.helm@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1721189?v=4"},"body":"On 4 May 2014 19:51:09 GMT+10:00, Felipe Contreras wrote:\n>James Denholm wrote:\n>> Felipe Contreras wrote:\n>> >David Lang wrote:\n>> >> the vast majority of people here do not take that attitude.\n>> >\n>> >It's actually the exact opposite. I don't care what is the track\n>record\n>> >of the people in the discussion.\n>> \n>> Ah, yes, like that discussion we once had where you totally didn't\n>run\n>> `git log | grep James Denholm` at one point to demonstrate that I had\n>> not yet made any contributions,instead of actually engaging in\n>> discussion. Oh, wait.\n>\n>You mean this thread[1] in which I sent 14 mails directly to you? Yeah,\n>I din't engage in that discussion at all!\n\nYeah, you didn't. Instead you danced, but I guess it's\nreally all said and done now so eh, have your point.\n\n>> >If their argument is good, their argument is good.\n>> \n>> The problem, though, is that time and time again you've shown that\n>you\n>> value your own arguments to the exclusion of all others. You can't\n>> tell if someone else's argument is good, because it runs against\n>> yours, and yours must be right because you hold it.\n>\n>I can show you evidence of how that's a blatant lie. Just two days ago\n>I\n>changed my mind because somebody provided a good argument.\n\nAnd I can show you evidence of you being\nindiscourseable on the topic of your pet proposals,\nbut I won't, because you're indiscourseable on the\nmeta similarly.\n\n>But I'm not going to bother any more with you, you are just spreading\n>lies and tainting the discussion.\n\nWell, maybe we'll see what other folks think.\n\nRegards,\nJames Denholm.\n"},{"id":"240682","messageId":"874n15vmau.fsf@fencepost.gnu.org","threadId":"36567","inReplyTo":"2bbbfedd-b224-4ef0-a611-fe78d3446db8@email.android.com","subject":"Re: Pull is Mostly Evil","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-04T11:02:49Z","receivedAt":"2014-05-04T11:02:49Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"James Denholm writes:\n\n> On 4 May 2014 19:51:09 GMT+10:00, Felipe Contreras\n> wrote:\n>\n>>But I'm not going to bother any more with you, you are just spreading\n>>lies and tainting the discussion.\n>\n> Well, maybe we'll see what other folks think.\n\nAccording to whose summary?\n\n\n\n-- \nDavid Kastrup\n"},{"id":"240697","messageId":"53669051.6090204@bbn.com","threadId":"36567","inReplyTo":"536613bd14e24_1c89b0930cac@nysa.notmuch","subject":"Re: Pull is Mostly Evil","fromName":"Richard Hansen","fromEmail":"rhansen@bbn.com","sentAt":"2014-05-04T19:09:05Z","receivedAt":"2014-05-04T19:09:05Z","isPatch":false,"sender":{"key":"rhansen@rhansen.org","avatar":null},"body":"On 2014-05-04 06:17, Felipe Contreras wrote:\n> Richard Hansen wrote:\n>> On 2014-05-03 23:08, Felipe Contreras wrote:\n>>> It is the only solution that has been proposed.\n>>\n>> It's not the only proposal -- I proposed a few alternatives in my\n>> earlier email (though not in the form of code), and others have too. In\n>> particular:\n>>\n>> * create a new 'git integrate' command/alias that behaves like 'git\n>> pull --no-ff'\n> \n> Yeah but that's for a different issue altogheter. I doesn't solve the\n> problems in 1. nor 2. nor 3.\n\n'git integrate' would handle usage cases #2 (update a published branch\nto its \"parent\" branch) and #3 (integrate a completed task into the main\nline of development), making it feasible to change 'git pull' and 'git\npull $remote [$refspec]' to default to --ff-only to handle usage case #1\n(update local branch to @{u}).\n\n> \n>> * change 'git pull' and 'git pull $remote [$refspec]' to do --ff-only\n>> by default\n>>\n>> Another option that I just thought of: Instead of your proposed\n>> pull.mode and branch..pullmode, add the following two sets of configs:\n>>\n>> * pull.updateMode, branch..pullUpdateMode:\n>>\n>> The default mode to use when running 'git pull' without naming a\n>> remote repository or when the named remote branch is @{u}. Valid\n>> options: ff-only (default), merge-ff, merge-ff-there, merge-no-ff,\n>> merge-no-ff-there, rebase, rebase-here, rebase-here-then-merge-no-ff\n> \n> Those are way too many options to be able to sensibly explain them.\n\nCertainly this is too many options for a first patch series, but I don't\nthink they're unexplainable. (I listed a bunch of options because I was\ntrying to envision where this might take us in the long run.)\n\nFor the first patch series, I'd expect: merge (which uses the merge.ff\noption to determine whether to ff, ff-only, or no-ff), rebase, and ff-only.\n\nLater ff-only would be made the default.\n\nLater some or all of the other options would be added depending on user\ninterest.\n\n> \n>> * pull.integrateMode, branch..pullIntegrateMode:\n>>\n>> The default mode to use when running 'git pull $remote [$refspec]'\n>> when '$remote [$refspec]' is not @{u}. Valid options are the same\n>> as those for pull.updateMode. Default is merge-ff.\n>>\n>> This gives the default split behavior as you propose, but the user can\n>> reconfigure to suit personal preference (and we can easily change the\n>> default for one or the other if there's too much outcry).\n> \n> If we reduce the number of options to begin with (more can be added\n> later),\n\nyup\n\n> then it might make sense to have these two options.\n> \n> However, that doesn't change the proposal you described above (1. 2.\n> 3.).\n\nNot sure what you mean. I oulined three usage cases:\n #1 update local branch to @{u}\n #2 update a published branch to its \"parent\" branch\n #3 integrate a completed task into the main line of development\n\nHaving these two sets of options (updateMode and integrateMode) would\nmake it possible to configure plain 'git pull' to handle usage case #1\nand 'git pull $remote [$refspec]' to handle usage cases #2 and #3.\n\nOr the user could configure 'git pull' and 'git pull $remote [$refspec]'\nto behave the same, in case they find the different behaviors to be too\nconfusing.\n\n> There's something we can do, and let me clarify my proposal. What you\n> described above is what I think should happen eventually, however, we\n> can start by doing something like what my patch series is doing; issue a\n> warning that the merge is not fast-forward and things might change in\n> the future.\n\nOK, let me rephrase to make sure I understand:\n\n 1. leave the default behavior as-is for now (merge with local\n branch the first parent)\n 2. add --merge argument\n 3. add ff-only setting\n 4. plan to eventually change the plain 'git pull' default to ff-only,\n but don't change the default yet\n 5. add a warning if the plain 'git pull' is a non-ff\n 6. wait and see how users react. If they're OK with it, switch the\n default of the plain 'git pull' to ff-only.\n\nIs that accurate? If so, sounds OK to me.\n\n> \n> If people find this behavior confusing they will complain in the mailing\n> list.\n\ntrue\n\n> Although I suspect it would be for other reasons, not the 'git\n> pull'/'git pull $there' division.\n\nprobably\n\n> Either way we would see in the discussion.\n\nsounds good to me\n\n> \n>>>>>> 3. integrate a more-or-less complete feature/fix back into the line\n>>>>>> of development it forked off of\n>>>>>>\n>>>>>> In this case the local branch is a primary line of development and\n>>>>>> the remote branch contains the derivative work. Think Linus\n>>>>>> pulling in contributions. Different situations will call for\n>>>>>> different ways to handle this case, but most will probably want\n>>>>>> some or all of:\n>>>>>>\n>>>>>> * rebase the remote commits onto local HEAD\n>>>>>\n>>>>> No. Most people will merge the remote branch as it is. There's no reason\n>>>>> to rebase, specially if you are creating a merge commit.\n>>>>\n>>>> I disagree. I prefer to rebase a topic branch before merging (no-ff) to\n>>>> the main line of development for a couple of reasons:\n>>>\n>>> Well that is *your* preference. Most people would prefer to preserve the\n>>> history.\n>>\n>> Probably. My point is that the behavior should be configurable, and I'd\n>> like that particular behavior to be one of the options (but not the\n>> default -- that wouldn't be appropriate).\n> \n> All right. But I'm a bit overwhelmed by all the things to keep in mind.\n\nSure, this would be an option to add later.\n\n> Does your proposed IntegradeMode/UpdateMode deal with this?\n\nmode = rebase-here-then-merge-no-ff would do what I described\n\n> Anyway, I'll try to grab what I can from previous discussions (mainly\n> about switching the merge parents) and create a new thread with a\n> summary.\n\nThat would be nice, thanks.\n\n-Richard\n"},{"id":"240703","messageId":"5366ad66b9a6c_18f9e4b308b8@nysa.notmuch","threadId":"36567","inReplyTo":"53669051.6090204@bbn.com","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-04T21:13:10Z","receivedAt":"2014-05-04T21:13:10Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Richard Hansen wrote:\n> On 2014-05-04 06:17, Felipe Contreras wrote:\n> > Richard Hansen wrote:\n> >> On 2014-05-03 23:08, Felipe Contreras wrote:\n> >>> It is the only solution that has been proposed.\n> >>\n> >> It's not the only proposal -- I proposed a few alternatives in my\n> >> earlier email (though not in the form of code), and others have too. In\n> >> particular:\n> >>\n> >> * create a new 'git integrate' command/alias that behaves like 'git\n> >> pull --no-ff'\n> > \n> > Yeah but that's for a different issue altogheter. I doesn't solve the\n> > problems in 1. nor 2. nor 3.\n> \n> 'git integrate' would handle usage cases #2 (update a published branch\n> to its \"parent\" branch) and #3 (integrate a completed task into the main\n> line of development),\n\nBut these cases are completely different. One should reverse the\nparents, the other one not.\n\nI feel if a new command is to be added, it should be the one that is\nintroducing the brand new behavior: switching the parents. So it would\nbe appropriate for 1. and 2.\n\n> >> * change 'git pull' and 'git pull $remote [$refspec]' to do --ff-only\n> >> by default\n> >>\n> >> Another option that I just thought of: Instead of your proposed\n> >> pull.mode and branch..pullmode, add the following two sets of configs:\n> >>\n> >> * pull.updateMode, branch..pullUpdateMode:\n> >>\n> >> The default mode to use when running 'git pull' without naming a\n> >> remote repository or when the named remote branch is @{u}. Valid\n> >> options: ff-only (default), merge-ff, merge-ff-there, merge-no-ff,\n> >> merge-no-ff-there, rebase, rebase-here, rebase-here-then-merge-no-ff\n> > \n> > Those are way too many options to be able to sensibly explain them.\n> \n> Certainly this is too many options for a first patch series, but I don't\n> think they're unexplainable. (I listed a bunch of options because I was\n> trying to envision where this might take us in the long run.)\n\nActually I think they are too many for any point in time.\n\nMaybe pull.updateArgs would make more sense.\n\n> For the first patch series, I'd expect: merge (which uses the merge.ff\n> option to determine whether to ff, ff-only, or no-ff), rebase, and ff-only.\n\nSeems sensible.\n\n> > then it might make sense to have these two options.\n> > \n> > However, that doesn't change the proposal you described above (1. 2.\n> > 3.).\n> \n> Not sure what you mean. I oulined three usage cases:\n> #1 update local branch to @{u}\n> #2 update a published branch to its \"parent\" branch\n> #3 integrate a completed task into the main line of development\n> \n> Having these two sets of options (updateMode and integrateMode) would\n> make it possible to configure plain 'git pull' to handle usage case #1\n> and 'git pull $remote [$refspec]' to handle usage cases #2 and #3.\n\nNot if by default they are already handled.\n\n> > There's something we can do, and let me clarify my proposal. What you\n> > described above is what I think should happen eventually, however, we\n> > can start by doing something like what my patch series is doing; issue a\n> > warning that the merge is not fast-forward and things might change in\n> > the future.\n> \n> OK, let me rephrase to make sure I understand:\n> \n> 1. leave the default behavior as-is for now (merge with local\n> branch the first parent)\n> 2. add --merge argument\n> 3. add ff-only setting\n> 4. plan to eventually change the plain 'git pull' default to ff-only,\n> but don't change the default yet\n> 5. add a warning if the plain 'git pull' is a non-ff\n> 6. wait and see how users react. If they're OK with it, switch the\n> default of the plain 'git pull' to ff-only.\n> \n> Is that accurate? If so, sounds OK to me.\n\nThat is what my patch series is doing already, basically.\n\nThe new warning I'm proposing would be for the split behavior of 'git\nmerge' and 'git merge $there'. Which is what is worrysome.\n\n> mode = rebase-here-then-merge-no-ff would do what I described\n\nI think that mode is way too specific to be useful for most people.\n\n-- \nFelipe Contreras\n"},{"id":"240706","messageId":"5367254E.5030402@bbn.com","threadId":"36567","inReplyTo":"5366ad66b9a6c_18f9e4b308b8@nysa.notmuch","subject":"Re: Pull is Mostly Evil","fromName":"Richard Hansen","fromEmail":"rhansen@bbn.com","sentAt":"2014-05-05T05:44:46Z","receivedAt":"2014-05-05T05:44:46Z","isPatch":false,"sender":{"key":"rhansen@rhansen.org","avatar":null},"body":"On 2014-05-04 17:13, Felipe Contreras wrote:\n> Richard Hansen wrote:\n>> On 2014-05-04 06:17, Felipe Contreras wrote:\n>>> Richard Hansen wrote:\n>>>> On 2014-05-03 23:08, Felipe Contreras wrote:\n>>>>> It is the only solution that has been proposed.\n>>>>\n>>>> It's not the only proposal -- I proposed a few alternatives in my\n>>>> earlier email (though not in the form of code), and others have too. In\n>>>> particular:\n>>>>\n>>>> * create a new 'git integrate' command/alias that behaves like 'git\n>>>> pull --no-ff'\n>>>\n>>> Yeah but that's for a different issue altogheter. I doesn't solve the\n>>> problems in 1. nor 2. nor 3.\n>>\n>> 'git integrate' would handle usage cases #2 (update a published branch\n>> to its \"parent\" branch) and #3 (integrate a completed task into the main\n>> line of development),\n> \n> But these cases are completely different. One should reverse the\n> parents, the other one not.\n\nNo -- for both #2 and #3 I want the remote branch to be merged into the\nlocal branch.\n\nIn the example I gave for use case #2, foo is a local branch with\norigin/foo as the configured upstream and origin/foo was forked off of\norigin/master. Someone pushed new stuff to origin/master, and the user\nwants the new stuff to also be in origin/foo. So the user does this:\n\n git checkout foo\n git pull --ff-only # this is use case #1\n git pull origin master # this is use case #2\n git push\n\nThe merge commit created by 'git pull origin master' should have\norigin/master as the second parent, not the first.\n\n-Richard\n"},{"id":"240716","messageId":"536725e522a80_2c827cb30c1c@nysa.notmuch","threadId":"36567","inReplyTo":"5367254E.5030402@bbn.com","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-05T05:47:17Z","receivedAt":"2014-05-05T05:47:17Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Richard Hansen wrote:\n> On 2014-05-04 17:13, Felipe Contreras wrote:\n> > Richard Hansen wrote:\n> >> On 2014-05-04 06:17, Felipe Contreras wrote:\n> >>> Richard Hansen wrote:\n> >>>> On 2014-05-03 23:08, Felipe Contreras wrote:\n> >>>>> It is the only solution that has been proposed.\n> >>>>\n> >>>> It's not the only proposal -- I proposed a few alternatives in my\n> >>>> earlier email (though not in the form of code), and others have too. In\n> >>>> particular:\n> >>>>\n> >>>> * create a new 'git integrate' command/alias that behaves like 'git\n> >>>> pull --no-ff'\n> >>>\n> >>> Yeah but that's for a different issue altogheter. I doesn't solve the\n> >>> problems in 1. nor 2. nor 3.\n> >>\n> >> 'git integrate' would handle usage cases #2 (update a published branch\n> >> to its \"parent\" branch) and #3 (integrate a completed task into the main\n> >> line of development),\n> > \n> > But these cases are completely different. One should reverse the\n> > parents, the other one not.\n> \n> No -- for both #2 and #3 I want the remote branch to be merged into the\n> local branch.\n\nI didn't mean #2 and #3, I meant (#1) vs. (#2, #3).\n\n-- \nFelipe Contreras\n"},{"id":"240760","messageId":"5367B096.80700@bbn.com","threadId":"36567","inReplyTo":"CAEBDL5USVuFDXQk7Cb9cJ8Lm4RJNeJB0DwZBCB1cXmkroD8w3g@mail.gmail.com","subject":"Re: Pull is Mostly Evil","fromName":"Richard Hansen","fromEmail":"rhansen@bbn.com","sentAt":"2014-05-05T15:39:02Z","receivedAt":"2014-05-05T15:39:02Z","isPatch":false,"sender":{"key":"rhansen@rhansen.org","avatar":null},"body":"On 2014-05-03 06:00, John Szakmeister wrote:\n> FWIW, at my company, we took another approach. We introduced a `git\n> ffwd` command that fetches from all remotes, and fast-forwards all\n> your local branches that are tracking a remote, and everyone on the\n> team uses it all the time. It should be said this team also likes to\n> use Git bare-metal, because they like knowing how things work\n> out-of-the-box. But they all use the command because it's so\n> convenient.\n\nI also wrote a script to fast-forward all local branches to their\nconfigured upstream refs. I finally got around to uploading it\nsomewhere public:\n\n https://github.com/richardhansen/git-update-branch\n\nI use it in my 'git up' alias:\n\n git config --global alias.up \\\n '!git remote update -p; git update-branch -a'\n\nIf there's interest I can tweak the style to conform to\nDocumentation/CodingGuidelines and stick it in contrib/ or something.\n\n-Richard\n"},{"id":"240765","messageId":"5367d549ae41c_25278db2ec2@nysa.notmuch","threadId":"36567","inReplyTo":"5367B096.80700@bbn.com","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-05T18:15:37Z","receivedAt":"2014-05-05T18:15:37Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Richard Hansen wrote:\n> On 2014-05-03 06:00, John Szakmeister wrote:\n> > FWIW, at my company, we took another approach. We introduced a `git\n> > ffwd` command that fetches from all remotes, and fast-forwards all\n> > your local branches that are tracking a remote, and everyone on the\n> > team uses it all the time. It should be said this team also likes to\n> > use Git bare-metal, because they like knowing how things work\n> > out-of-the-box. But they all use the command because it's so\n> > convenient.\n> \n> I also wrote a script to fast-forward all local branches to their\n> configured upstream refs. I finally got around to uploading it\n> somewhere public:\n> \n> https://github.com/richardhansen/git-update-branch\n> \n> I use it in my 'git up' alias:\n> \n> git config --global alias.up \\\n> '!git remote update -p; git update-branch -a'\n> \n> If there's interest I can tweak the style to conform to\n> Documentation/CodingGuidelines and stick it in contrib/ or something.\n\nI think this would fit perfectly in the proposed `git update` command as\nan option: `git update --all`.\n\n-- \nFelipe Contreras\n"},{"id":"240845","messageId":"xmqqy4yed0jq.fsf@gitster.dls.corp.google.com","threadId":"36567","inReplyTo":"20140502214817.GA10801@sigill.intra.peff.net","subject":"Re: Pull is Mostly Evil","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-06T22:06:49Z","receivedAt":"2014-05-06T22:06:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I realize this has veered off into talking about an \"update\" command,\n> and not necessarily \"pull\", but since there a lot of proposals floating\n> around, I wanted to make one point: if we are going to do such a switch,\n> let's please make it something the user explicitly turns on.\n\nI mentioned \"update\" in an attempt to suggest some way to avoid\nbreaking \"git pull\" for people who do want to advane the history\nwith real work (i.e. not just following along with fast-forwarding).\n\nA failed \"git push\" that suggests to pull first, which came from the\noriginal \"To emulate CVS workflow, you can pull, work, push, and if\nthe push fails, pull again and then push\" in the early tutorial,\nturns out to be very bad in the \"trunk\" centric worldview.\nAnd I think the solution is to realize that we use \"git pull\" for\ntwo fairly differnt workflows.\n\n - You know you own the tip of the \"trunk\" (in the global view).\n You merge from other people to advance the global world view in a\n way that makes sense in the \"first-parent chain is the trunk\"\n worldview. That is what \"git pull [--no-ff]\" was designed to do,\n and it does it very well.\n\n - You have some work of yours (either you committed directly, you\n merged your own work done on a side branch, or you merged from\n other people using \"git pull\") on top of a commit that used to be\n at the tip of the global world. You want to make sure that\n branch you are on is not missing what has happened while you are\n not communicating with the outside world.\n\nThe problematic case is the latter, and by introducing a new command\nto do that well (which is *not* just about \"swapping the order of\nthe parents\", by the way), updating the \"leaf developer\" section of\n\"Everyday Git\" document and tutorials, and suggesting to use that\nupon failed \"git push\", I think users would get a more pleasant\nexperience. And move \"git pull\" into \"integrator\" section, a\ncommand that is not necessary for leaf developers.\n\nI am not married to the name \"update\". I think the ideal behaviour\nof that \"leaf-developer\" command would be something along the lines\nof the following:\n\n - If we can fast-forward, do so and we are done.\n\n - Otherwise, we have a history of this shape:\n\n ----O \n \\\n -----A----B----C\n \\\n X---Y---Z\n\n where A was where we forked, B was a merge the user made, C was a\n commit the user directly made, and X, Y, and Z (some of them may\n be merges) are the \"trunk\" history \"git pull\" would create a\n merge M whose parents are , which is wrong from the\n \"first-parent is the trunk\" worldview.\n\n But recording the merge to have parents does not give us\n \"the first-parent is the trunk\" worldview, in the presense of B.\n We would prefer to end up with a history more like this:\n\n -----A ----O\n \\ \\\n X---Y---Z---B'--C'\n\n so that your work, your contribution with two commits of yours,\n was to merge the work done on a side branch and then made one\n commit directly on top of it.\n\n Hence, I think the ideal behaviour of the new command is to\n replay the first-parent history on top of the updated tip of your\n upstream (which by the way is different from how \"rebase\n --preserve-merges\" works; it is more like how J6t wanted to make\n \"rebase --preserve-merges\" work, IIRC).\n\nAfter that, you can attempt to push, and it may fail again (because\nsomebody has grown the shared history to have a child W of Z at the\ntip), in which case exactly the same \"git update\" would attempt to\nrecreate a history of this shape:\n\n -----A ----O\n \\ \\\n X---Y---Z---W---B\"--C\"\n\n\nDuring a long transition period (essentially, waiting for the\ncurrent crop of documents and tutorials to die out), we will need\nextra safety to prevent people, who merely wanted to bring their\nbranch up to date, from running \"git pull\", and I think the command\nneeds to:\n\n - check which branch of what repository it is trying to pull;\n\n - check which branch of what repository it is going to update if\n \"git push\" is given;\n\n - if they are the same, then you are attempting to update from your\n upstream, so either warn or error out. If we are going to warn\n but make a merge anyway, the warning message *must* come at the\n very end of the output (and tell the user the way to recover is\n to reset one away and run the other command).\n\nOr something like that.\n"},{"id":"240849","messageId":"53695ff6b1535_747f1521308c5@nysa.notmuch","threadId":"36567","inReplyTo":"xmqqy4yed0jq.fsf@gitster.dls.corp.google.com","subject":"Re: Pull is Mostly Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-06T22:19:34Z","receivedAt":"2014-05-06T22:19:34Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> But recording the merge to have parents does not give us\n> \"the first-parent is the trunk\" worldview, in the presense of B.\n> We would prefer to end up with a history more like this:\n> \n> -----A ----O\n> \\ \\\n> X---Y---Z---B'--C'\n> \n> so that your work, your contribution with two commits of yours,\n> was to merge the work done on a side branch and then made one\n> commit directly on top of it.\n\nYes, _ideally_, but as it has been explained multiple times most Git\nbeginners have no idea what is a rebase.\n\nWe might evenaully do this by default, but first we should start\nrejecting the update by default and recommending `git update --merge` as\nit has been discussed quite a lot should be the behavior of `git pull`.\n\n> Hence, I think the ideal behaviour of the new command is to\n> replay the first-parent history on top of the updated tip of your\n> upstream (which by the way is different from how \"rebase\n> --preserve-merges\" works; it is more like how J6t wanted to make\n> \"rebase --preserve-merges\" work, IIRC).\n\nWhat is the difference with 'rebase -p'?\n\n-- \nFelipe Contreras\n"},{"id":"240973","messageId":"20140507223752.GA13933@wheezy.local","threadId":"36567","inReplyTo":"5364A143.1060404@bbn.com","subject":"Re: Pull is Mostly Evil","fromName":"Max Kirillov","fromEmail":"max@max630.net","sentAt":"2014-05-07T22:37:52Z","receivedAt":"2014-05-07T22:37:52Z","isPatch":false,"sender":{"key":"max@max630.net","avatar":"https://avatars.githubusercontent.com/u/381560?v=4"},"body":"Hi.\n\nI might be late to this discussion, but here either\nsomething I don't understand or something is missed.\n\nOn Sat, May 03, 2014 at 03:56:51AM -0400, Richard Hansen wrote:\n> In my experience 'git pull' is mostly (only?) used for the following\n> three tasks:\n> \n> 1. update a local branch to incorporate the latest upstream changes\n> \n> In this case, the local branch (master) is a\n> derivative of the upstream branch (origin/master).\n> The user wants all of the commits in the remote branch\n> to be in the local branch. And the user would like\n> the local changes, if any, to descend from the tip of\n> the remote branch.\n> \n> For this case, 'git pull --ff-only' followed by 'git\n> rebase -p' works well, as does 'git pull\n> --rebase=preserve' if the user is comfortable rebasing\n> without reviewing the incoming commits first. A plain\n> 'git pull' or 'git pull --ff' is suboptimal due to the\n> awkward backwards-parents merge commit.\n\nThis is actually not a finally defined use case. What kind\nof \"local changes\" user can have ahead of the remote? As\nfar I understand, there are 3 cases:\n\n 1a. Changes that are going to be merged back to the master,\n but not yet ready to be there.\n\nThis is essentially the same as case 2, but it does not name\nthe development branch explicitely. Switching parents for\nthis case is not desirable.\n\n 1b. Some truly local changes which never goes anywhere.\n\nFor this case the parent order does not matter.\n\n 1c. The local changes prepared for integration, but instead\n of filing a pull request of otherwise publishing the\n branch for integrator, the leaf developer does the\n integrator's job and merges it back to master and then\n publishing the master.\n\nAs far as I understand, this is the only case when somebody\nwould want the parents to be switched. And this does not\nseem to be a good practice, because it's prone to push races\nand requires letting everyone to push to master. So maybe\ngit should not encourage people to do so.\n\nAnd the name \"update\", proposed here, does not seem to be\ncorrect. Because what happens is not updating, but merging\nfeature to master and closing it.\n\n> 2. update a published feature branch with the latest\n> changes from its parent branch\n\n> 3. integrate a more-or-less complete feature/fix back\n> into the line of development it forked off of\n\n-- \nMax\n"},{"id":"241220","messageId":"536D3145.7080305@xiplink.com","threadId":"36567","inReplyTo":"5363BB9F.40102@xiplink.com","subject":"Re: Pull is Mostly Evil","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2014-05-09T19:49:25Z","receivedAt":"2014-05-09T19:49:25Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"After poking this hornet's nest I pretty much have stood back and not\nparticipated in the ensuing discussions. But having unleashed the hornets I\nfeel I should at least say something, if only to assure people that I'm not\nignoring their plight.\n\nThere have been various proposals to modify git-pull's defaults, and/or\nextend it with new configuration settings, and/or add a new command. As I\ndon't use \"git pull\" I feel I'm not in any position to comment about the\nparticulars of these proposals.\n\nHowever I remain skeptical that these proposals, in any form, will really be\nall that helpful to new users. That's because in order to know whether or\nnot \"git pull\" (or \"git update\") does what the user wants, the user has to\nunderstand the intricacies of both their own workflow and how git can work\nwithin that workflow. By the time a user gains that understanding, she is no\nlonger a new user.\n\nStill, I do think the pull command is useful. In particular I think that a\nproject can benefit greatly by tailoring pull's behaviour to match its\nworkflow, and that a project's participants can be told how to configure git\nso that pull works properly for that project. Maybe even such configuration\n-- a \"workflow blueprint\" if you will -- can be tracked inside the project\nitself, so that a fresh project clone can automatically have \"git pull\"\nproperly configured. To me this seems like a fabulous feature for git.\n\nBut for now I go back to what I said before: Give \"git pull\" enough knobs to\nlet people tailor it to their individual projects' needs. But also disable\n\"git pull\" by default, because nobody should run it until they've considered\nhow they want it to work.\n\n\t\tM.\n"}]}