{"thread":{"id":"36589","subject":"Summary of the problems with git pull","startedAt":"2014-05-06T10:58:03Z","lastAt":"2014-05-06T10:58:03Z","messageCount":1,"participants":["Felipe Contreras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"240784","messageId":"CAMP44s1tJAGVcQc=Y5L5TP7MTro9C9hPnN1NR-nDT3YczjwjTA@mail.gmail.com","threadId":"36589","inReplyTo":null,"subject":"Summary of the problems with git pull","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-06T10:58:03Z","receivedAt":"2014-05-06T10:58:03Z","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"}]}