{"thread":{"id":"36582","subject":"Summary of the problems with git pull","startedAt":"2014-05-05T00:29:40Z","lastAt":"2014-05-28T08:39:19Z","messageCount":6,"participants":["Felipe Contreras","Damien Robert","Ping Yin","Philippe Vaucher"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"240719","messageId":"5366db742d494_18f9e4b308aa@nysa.notmuch","threadId":"36582","inReplyTo":null,"subject":"Summary of the problems with git pull","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-05T00:29:40Z","receivedAt":"2014-05-05T00:29:40Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nThere has been a lot of discussion about why `git pull` is broken for so\nmany many workflows: [1][2][3][4][5], even as far back as [6].\n\nMany issues has been brought up, and many proposed solutions, probably\ntoo many for most people properly digest them, so here I'll try to\nsynthesize them.\n\nMainly there are two core problems with `git pull`:\n\n 1) Many times it does a merge when it's not when people want\n 2) Many times it does a merge opposite of the desired direction\n\nThe issue comes in trying to solve these problems in a way that would\nnot affect anybody negatively.\n\nThe simplest way to fix these issues unobtrusively would be to add\nconfigurations for the new behavior. However, this wouldn't solve the\nproblem because as it has been discussed the vast majority of people\ndoing these \"bad merges\" are not advanced users, so they wouldn't\nactivate these options.\n\nWhat is needed is to change the default behavior, but in a way that is\nnot obtrusive, and with backwards compatibility configuration.\n\nThe most concrete proposal is my patch series that puts everything in\nplace to enable fast-forward merged by default only. However, that still\ndoesn't solve the problem of the ordering of parents. Normally these two\nissues would be independent of each other, but after further analysis I\nthink they are not.\n\n== Two different kinds of pulls ==\n\nIt has become clear that the `git pull` command is in fact used to do\ntwo very different things:\n\n 1) Update the current branch\n\nMost people do `git pull` like they would do `svn update`; to update\ntheir current branch.\n\n 2) Merge a remote branch\n\nThere are many use-cases of this.\n\nThe agreement so far is that 1) is the one that is broken, that is; a)\nby default only fast-forwards should be allowed, and b) when a merge\nhappens the parents should be reverted (merge 'master' to\n'origin/master').\n\nIt would be possible to differentiate these kinds by saying a `git pull`\nthat doesn't specify the location can be assumed as 1), and a\n`git pull remote branch` that does as 2). Another possibility is to\nassume only the upstream branch corresponds to 1).\n\nUnfortunately it's the feeling of many people that this solution is not\n\"clean\", because it's two very different behaviors for the same command.\nFurthermore even deeper analysis of the use-cases demonstrates there\nwould be a need to have different configurations for the different modes\n(e.g. pull.updateMode and pull.integrateMode).\n\n== git update ==\n\nAnother proposed solution is to have a new command: `git update`. This\ncommand would be similar to `git pull --ff-only` by default, but it\ncould be configured to do merges instead, and when doing so in reverse.\n\nAn interesting side-effect of this new command is that it opens the\npossibility of thinking about `git update --rebase` vs.\n`git pull --rebase`.\n\nFor example:\n\n  a) git update --merge\n\n     Merge HEAD into @{upstream}\n\n  b) git update --rebase\n\n     Rebase HEAD onto @{upstream}\n\n  c) git pull --merge github john\n\n     Merge github/john into HEAD\n\n  d) git pull --rebase github john\n\n     Rebase github/john onto HEAD\n\nNotice how the relationships between them are nice and consistent. Also,\nd) was not possible before.\n\nThis solves essentially all the issues people presented in their\nuse-cases, except the differentiation between merging topic and upstream\nbranches, for which we might want to add different options in\n`git pull`, but that's independent from the issues I mentioned at the\nbeginning.\n\nNothing changes for the users of `git pull`, except that perhaps we\nwould want --rebase to work in reverse, since the current\n`git pull --rebase` would already rebase HEAD onto @{upstream}.\n\nPersonally my next step would be to port the changes I did for\npull.mode = merge-ff-only into a new command `git update`, which would\nprobably be a copy-paste from `git pull` and see how that turns out. In\naddition, when running `git pull` without arguments we might want to add\na temporary notice explaining that perhaps the user wanted to type\n`git update` instead.\n\nCheers.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/233554\n[2] http://article.gmane.org/gmane.comp.version-control.git/234295\n[3] http://article.gmane.org/gmane.comp.version-control.git/225146\n[4] http://article.gmane.org/gmane.comp.version-control.git/247237\n[5] http://article.gmane.org/gmane.comp.version-control.git/247939\n[6] http://article.gmane.org/gmane.comp.version-control.git/130819\n\n-- \nFelipe Contreras\n"},{"id":"240833","messageId":"lkbf63$p8l$1@ger.gmane.org","threadId":"36582","inReplyTo":"5366db742d494_18f9e4b308aa@nysa.notmuch","subject":"Re: Summary of the problems with git pull","fromName":"Damien Robert","fromEmail":"damien.olivier.robert+gmane@gmail.com","sentAt":"2014-05-06T20:03:15Z","receivedAt":"2014-05-06T20:03:15Z","isPatch":false,"sender":{"key":"damien.olivier.robert+gmane@gmail.com","avatar":null},"body":"Felipe Contreras  wrote in message\n<5366db742d494_18f9e4b308aa@nysa.notmuch>:\n> == git update ==\n> \n> Another proposed solution is to have a new command: `git update`. This\n> command would be similar to `git pull --ff-only` by default, but it\n> could be configured to do merges instead, and when doing so in reverse.\n\nThanks for the nice summary.\n\nAs a user, I am very much in favor of adding a `git update` command. In\nfact I already have a ruby script that does such a thing (fast-forward all my\nlocal branches that have an upstream configured), so it would be nice to\nhave it directly in git core.\n"},{"id":"240882","messageId":"CACSwcnQDtf5pE2Uoab68ZmQ-1K9MWTZaR_b7qExDd2myY8h+kg@mail.gmail.com","threadId":"36582","inReplyTo":"5366db742d494_18f9e4b308aa@nysa.notmuch","subject":"Re: Summary of the problems with git pull","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2014-05-07T10:39:01Z","receivedAt":"2014-05-07T10:39:01Z","isPatch":false,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"Ping Yin\n\n\nOn Mon, May 5, 2014 at 8:29 AM, Felipe Contreras\n<felipe.contreras@gmail.com> wrote:\n> Hi,\n>\n> == git update ==\n>\n> Another proposed solution is to have a new command: `git update`. This\n> command would be similar to `git pull --ff-only` by default, but it\n> could be configured to do merges instead, and when doing so in reverse.\n>\n+1 for git update\n"},{"id":"241241","messageId":"536de90320f06_239010732fc82@nysa.notmuch","threadId":"36582","inReplyTo":"5366db742d494_18f9e4b308aa@nysa.notmuch","subject":"RE: Summary of the problems with git pull","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-10T08:53:23Z","receivedAt":"2014-05-10T08:53:23Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Felipe Contreras wrote:\n> == git update ==\n> \n> Another proposed solution is to have a new command: `git update`. This\n> command would be similar to `git pull --ff-only` by default, but it\n> could be configured to do merges instead, and when doing so in reverse.\n\nAnd here it is:\n\nhttps://github.com/felipec/git/commits/fc/update\n\nHere's the documentation:\n\nhttps://github.com/felipec/git/wiki/git-update\n\nWorks exactly as expected: non-fast-forwards are rejected by default,\nbut can be configured, and parents are reversed when merging.\n\n-- \nFelipe Contreras\n"},{"id":"242843","messageId":"CAGK7Mr4uucBN=17ph5pBjrz7yP60By1sERU9oBL+c2-gsMDmrw@mail.gmail.com","threadId":"36582","inReplyTo":"536de90320f06_239010732fc82@nysa.notmuch","subject":"Re: Summary of the problems with git pull","fromName":"Philippe Vaucher","fromEmail":"philippe.vaucher@gmail.com","sentAt":"2014-05-28T07:13:32Z","receivedAt":"2014-05-28T07:13:32Z","isPatch":false,"sender":{"key":"philippe.vaucher@gmail.com","avatar":null},"body":"> Felipe Contreras wrote:\n>> == git update ==\n>>\n>> Another proposed solution is to have a new command: `git update`. This\n>> command would be similar to `git pull --ff-only` by default, but it\n>> could be configured to do merges instead, and when doing so in reverse.\n>\n> And here it is:\n>\n> https://github.com/felipec/git/commits/fc/update\n>\n> Here's the documentation:\n>\n> https://github.com/felipec/git/wiki/git-update\n>\n> Works exactly as expected: non-fast-forwards are rejected by default,\n> but can be configured, and parents are reversed when merging.\n\nI know patches from Felipe are sensitive subject and that a lot of\npeople probably simply ignore him entirely, however I think this patch\ndeserves more attention.\n\n>From what I read, it seems to really improve the \"pull\" issues and is\nmore or less in line with what Junio suggested what should be done in\n[1]. So the goal of this mail is just to make sure people consider it\nfor inclusion.\n\nSorry if I missed a thread where it was already decided not to include it.\n\nFelipe, please don't use this to start any non-constructive behavior\n(rant on who is right/wrong, \"my patches are not accepted\", etc).\n\nPhilippe\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/248258\n"},{"id":"242850","messageId":"5385a0b7c1722_61910632f8a2@nysa.notmuch","threadId":"36582","inReplyTo":"CAGK7Mr4uucBN=17ph5pBjrz7yP60By1sERU9oBL+c2-gsMDmrw@mail.gmail.com","subject":"Re: Summary of the problems with git pull","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-28T08:39:19Z","receivedAt":"2014-05-28T08:39:19Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philippe Vaucher wrote:\n> Sorry if I missed a thread where it was already decided not to include\n> it.\n> \n> Felipe, please don't use this to start any non-constructive behavior\n> (rant on who is right/wrong, \"my patches are not accepted\", etc).\n\nI never sent those patches. I gave up on the Git project.\n\n-- \nFelipe Contreras\n"}]}