{"thread":{"id":"36513","subject":"A failing attempt to use Git in a centralized environment","startedAt":"2014-04-28T06:29:07Z","lastAt":"2014-05-04T20:54:10Z","messageCount":73,"participants":["Marat Radchenko","Junio C Hamano","Marc Branchaud","Stepan Kasal","Felipe Contreras","Matthieu Moy","Geert Bosch","Jonathan Nieder","brian m. carlson","W. Trevor King","Philip Oakley","Andreas Krey","David Kastrup","Max Kirillov","John Szakmeister"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"239833","messageId":"4ay6w9i74cygt6ii1b0db7wg.1398433713382@email.android.com","threadId":"36513","inReplyTo":null,"subject":"A failing attempt to use Git in a centralized environment","fromName":"Marat Radchenko","fromEmail":"marat@slonopotamus.org","sentAt":"2014-04-28T06:29:07Z","receivedAt":"2014-04-28T06:29:07Z","isPatch":false,"sender":{"key":"marat@slonopotamus.org","avatar":"https://avatars.githubusercontent.com/u/92637?v=4"},"body":"Setup:\n20 people (programmers, artists, designers) with prior SVN knowledge and a desire to use Git for a new project (mostly on programmers side). Non-programmers used TortoiseSVN before so choosing TortoiseGit as a GUI was an obvios step.\n\nWe made an in-house presentation introducing basic Git concepts and how it is different from SVN. Also, individual training was done for each person who didn't have Git experience. During this training, they tried everyday tasks of updating, committing, pushing changes and viewing history on a toy repository. \n\nProblem #1: TortoiseGit GUI windows for common tasks have a heck lots of controls that a common Git user will never need. Just look at a monstrosity of its push dialog [1]. This was kinda fixed by training users to use Git Sync dialog [2].\n\n\"Autoload PuTTY key\"? What the hell is this? Why I can switch it on/off in Git Push but it is disabled in Git Sync? What is PuTTY doing here at all, I'm using OpenSSH.\n\nProblem #2 occured the first day we started using Git on real project. It is explained in detail in older post to Git ML [3]. I call it \"swapped/reverse merge problem\".\n\nIn short:\n1. Hack, hack, hack\n2. Commit\n3. Push, woops, reject (non-ff)\n4. Pull\n5. Push\n\nThe root of evil is step #4 that creates a merge commit with \"swapped\" parents - local commits become first parent, remote commits become second. If one would want to make proper parent order, he would have to:\n1. git fetch\n2. git checkout origin/master -b tmp\n3. git merge master\n4. git push\n5. git checkout master\n6. git merge origin/master\n7. git branch -d tmp\n\nAnd all this branch dance produces exactly the same commit (content-wise) as simple \"pull, push\" sequence with the only difference in parent order. And things become even worse if comeone pushes more commits to remote repo while you perform this dance.\n\nWe can't expect all developers (especially, designers and artist) to do it. They don't want to use branches and just work on mainline. This is especially important on early development stages when new features (that designers' work depends upon) are added every day.\n\nAdditionally, many git-related tools depend on first-parent convention and show wrong graphs/diffs.\n\nProblem #3: on conflicts, user ends up with a working copy that marks all remote-changed files as modified. Luckily, nobody has problems with conflict resolution process, it's just confusing to see changes other way round.\n\nOkay, then, let's try rebase workflow. \"git config pull.rebase true\" and go.\n\nProblem #4: when conflict happens during rebase, mergetool shows user own changes as \"theirs\" and remote changes as \"mine\". And believe me, explaining this to users doesn't increase their willingness to adopt Git.\n\nProblem #5 (TortoiseGit-related): for some dumb reason, TortoiseGit's rebase is not a git rebase! Worse, TortoiseGit doesn't have any button to say 'git rebase --continue\". So we had to cancel \"pull.rebase=true\" approach and teach users to use \"Fetch&Rebase\" button. It would be usable if only TortoiseGit didn't show rebase dialog even when everything was already up-to-date. And even git-aware developers don't understand the idea behind \"Force rebase\" checkbox in rebase dialog and why anyone would ever want to have it disabled (and it is disabled by default).\n\nProblem #6: push - reject - pull - push sequence sometimes transforms into a loop with several iterations and doesn't add happiness.\n\nSo... Any suggestions how to make life easier are welcome.\n\n[1] http://tortoisegit.googlecode.com/git/doc/images/en/GitPush.png\n[2] http://tortoisegit.googlecode.com/git/doc/images/en/GitSync.png\n[3] http://git.661346.n2.nabble.com/first-parent-commit-graph-layout-and-pull-merge-direction-td7586671.html"},{"id":"240003","messageId":"xmqqoazlqot4.fsf@gitster.dls.corp.google.com","threadId":"36513","inReplyTo":"4ay6w9i74cygt6ii1b0db7wg.1398433713382@email.android.com","subject":"Re: A failing attempt to use Git in a centralized environment","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-28T18:41:43Z","receivedAt":"2014-04-28T18:41:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marat Radchenko writes:\n\n> Problem #1: TortoiseGit GUI windows for common tasks have a heck\n> lots of controls that a common Git user will never need.\n\nDo people around TortoiseGit lurk on this list? Otherwise this may\nnot be something we can help you with here.\n\n> Problem #2 occured the first day we started using Git on real\n> project. It is explained in detail in older post to Git ML [3]. I\n> call it \"swapped/reverse merge problem\".\n>\n> In short:\n> 1. Hack, hack, hack\n> 2. Commit\n> 3. Push, woops, reject (non-ff)\n> 4. Pull\n> 5. Push\n>\n> The root of evil is step #4 that creates a merge commit with\n> \"swapped\" parents.\n\nYes, this is a real issue, and I do not mind seeing a patch to\nimprove the situation (there may be different approaches, and one\nrandom approach somebody takes may not necessarily be a good way to\nimprove the situation though).\n\n - Perhaps by allowing an option to tell the \"pull\" at the fourth\n step to record swapped parents in the merge?\n\n - Perhaps in step #3, stop suggesting to \"pull first\" and instead\n tell them to \"fetch upstream, rebase your work on it and then\n push\"?\n\n - Extending on the second one, wrap a large part of the procedure\n in a single handy wrapper \"git update\" or something, whose point\n is to \"update your work to be mergeable and pushable\"?\n\n> Problem #3: on conflicts, user ends up with a working copy that\n> marks all remote-changed files as modified. Luckily, nobody has\n> problems with conflict resolution process, it's just confusing to\n> see changes other way round.\n\nIf we flip the resolution process to \"apply/merge your work to the\nupdated upstream (i.e. the topic of your problem #2 above)\", that\n\"other way round\" issue will disappear, no?\n>\n> Problem #4: when conflict happens during rebase, mergetool shows\n> user own changes as \"theirs\" and remote changes as \"mine\". And\n> believe me, explaining this to users doesn't increase their\n> willingness to adopt Git.\n\nLikewise.\n"},{"id":"240307","messageId":"536106EA.5090204@xiplink.com","threadId":"36513","inReplyTo":"xmqqoazlqot4.fsf@gitster.dls.corp.google.com","subject":"Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2014-04-30T14:21:30Z","receivedAt":"2014-04-30T14:21:30Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 14-04-28 02:41 PM, Junio C Hamano wrote:\n> Marat Radchenko writes:\n> \n>> Problem #1: TortoiseGit GUI windows for common tasks have a heck\n>> lots of controls that a common Git user will never need.\n> \n> Do people around TortoiseGit lurk on this list? Otherwise this may\n> not be something we can help you with here.\n> \n>> Problem #2 occured the first day we started using Git on real\n>> project. It is explained in detail in older post to Git ML [3]. I\n>> call it \"swapped/reverse merge problem\".\n>>\n>> In short:\n>> 1. Hack, hack, hack\n>> 2. Commit\n>> 3. Push, woops, reject (non-ff)\n>> 4. Pull\n>> 5. Push\n>>\n>> The root of evil is step #4 that creates a merge commit with\n>> \"swapped\" parents.\n> \n> Yes, this is a real issue, and I do not mind seeing a patch to\n> improve the situation (there may be different approaches, and one\n> random approach somebody takes may not necessarily be a good way to\n> improve the situation though).\n> \n> - Perhaps by allowing an option to tell the \"pull\" at the fourth\n> step to record swapped parents in the merge?\n> \n> - Perhaps in step #3, stop suggesting to \"pull first\" and instead\n> tell them to \"fetch upstream, rebase your work on it and then\n> push\"?\n\nThis approach would be my preference.\n\nBut I'm definitely biased because I think pull is pretty much broken:\n\n* New users are encouraged to use pull, but all too often the default\nfetch-then-merge behaviour doesn't match their expectations and they end up\nstarting threads like this one on the mailing list.\n\n* If we change pull's default behaviour, we'll just be shifting the\nmismatched expectations onto the other half of the new users who would be\nhappy with fetch-then-merge.\n\n* I'm not sure why new users are taught to use pull. I suspect it's because\nit tries to hide the idea of local-vs-remote branches, and people writing git\ntutorials don't want to overwhelm new users with what seems to be an internal\ndetail. But these notions are really fundamental to using git effectively,\nand I think pull does everyone a disservice by trying to gloss them over.\n\nAnyway, rather than ranting on I'll just suggest that there's not enough\ncommonality between the ways people use git to make it worthwhile trying to\nteach pull how to deal with a significant number of them. I think the pull\ncommand should be deprecated and quietly retired as a failed experiment.\n\n\t\tM.\n"},{"id":"240308","messageId":"xmqqppjyhnom.fsf@gitster.dls.corp.google.com","threadId":"36513","inReplyTo":"536106EA.5090204@xiplink.com","subject":"Re: Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-30T14:55:21Z","receivedAt":"2014-04-30T14:55:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n> But I'm definitely biased because I think pull is pretty much broken:\n>\n> * New users are encouraged to use pull, but all too often the default\n> fetch-then-merge behaviour doesn't match their expectations and they end up\n> starting threads like this one on the mailing list.\n>\n> * If we change pull's default behaviour, we'll just be shifting the\n> mismatched expectations onto the other half of the new users who would be\n> happy with fetch-then-merge.\n>\n> * I'm not sure why new users are taught to use pull. I suspect it's because\n> it tries to hide the idea of local-vs-remote branches, and people writing git\n> tutorials don't want to overwhelm new users with what seems to be an internal\n> detail. But these notions are really fundamental to using git effectively,\n> and I think pull does everyone a disservice by trying to gloss them over.\n>\n> Anyway, rather than ranting on I'll just suggest that there's not enough\n> commonality between the ways people use git to make it worthwhile trying to\n> teach pull how to deal with a significant number of them. I think the pull\n> command should be deprecated and quietly retired as a failed experiment.\n\nI almost agree with the first sentence in the last paragraph, and\nyour bulletted list above supports it.\n\nI am not sure how the second sentence can follow as its consequence.\n\nIf the conclusion were \"maybe adding a 'git update' to match the\nexpectation of those who build on top of the work of others (aka\nCVS/SVN style) more closely and teaching new users to use that\ninstead of 'git pull' may be a good way forward\", I can sort of\nunderstand (if I may not be able to immediately agree with, until I\ncan regurgitate the ramifications of such a change) it.\n"},{"id":"240317","messageId":"20140430161215.GA24017@camelia.ucw.cz","threadId":"36513","inReplyTo":"4ay6w9i74cygt6ii1b0db7wg.1398433713382@email.android.com","subject":"Re: A failing attempt to use Git in a centralized environment","fromName":"Stepan Kasal","fromEmail":"kasal@ucw.cz","sentAt":"2014-04-30T16:12:15Z","receivedAt":"2014-04-30T16:12:15Z","isPatch":false,"sender":{"key":"kasal@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/1481596?v=4"},"body":"Hello Marat,\n\nOn Mon, Apr 28, 2014 at 10:29:07AM +0400, Marat Radchenko wrote:\n> Setup:\n> 20 people (programmers, artists, designers) with prior SVN\n\nI was in a similar situation: 10 people, mostly mathematicians,\nprevious experience with Tortoise SVN.\n\nI wanted to move to Git with centralized model. I call it a success:\npeople can do basic changes on master and also can work with\nbranches, if they don't want to break master. (Much better than\nkeeping uncommitted changes at a svn checkout.)\n\nI avoided TortoiseGit because I thought it would make the switch more\ncomplicated: Git does differ from SVN, and it cannot be hidden.\n\nWe use Git Extensions (Windows only frontend).\nI like it, as it is very close to command-line, so it is easy for me\nto provide support. It also improves the dialogs by hiding all the\nadvanced options; you have to click on \"advanced\" to get the full\nlist.\n\nWhen working on master, pull --rebase is a necessity:\nThe install procedure does set config\n branch.autosetuprebase = always\n(Must be done before any clone, so that all branches created after\nthat are set up to rebase, rtfm...)\n\nI also told people to check \"Rebase\" in the pull dialog (it is\npersistent then).\n\nAnd I provided snapshots, so they immediatly call for help if they\nsee non-linear history.\n\n> Problem #4: when conflict happens during rebase, mergetool shows\n> user own changes as \"theirs\" and remote changes as \"mine\". And\n> believe me, explaining this to users doesn't increase their\n> willingness to adopt Git.\n\nOur mergetool is Kdiff3. (Git Extensions are willing to install it;\nwe did that separately to get a newer 64bit version.)\nKdiff3 shows three columns; their names (BASE, LOCAL, etc.) are\nconfusiong, but in our case it was easy to ignore them; we had no\nprevious experience with merge conflicts resolving.\n\n> Problem #6: push - reject - pull - push sequence sometimes\n> transforms into a loop with several iterations and doesn't add\n> happiness.\n\nI told people to do \"pull-push\" always when they want to push.\nIf the pull has conflicts, then they naturally do \"pull-push\" again\nafter the conflicts are resolved.\n\nGit Extensions has its problems, you may look at the issue tracker;\nI created several reports when exploring it (login kasal).\n\nI would mention:\nhttps://github.com/gitextensions/gitextensions/issues/2241\n\nIf you pull on a non-tracking branch, it creates a false\norigin/branchname from origin/HEAD. The bug was fixed, but there was\nno release since then: so you have to live with it or you have to\nbuild Git Extensions yourself in Visual Studio.\n\nI had to write this in haste; hope this helps you anyway.\n\nStepan\n"},{"id":"240335","messageId":"536129068cc28_1404fdd310fd@nysa.notmuch","threadId":"36513","inReplyTo":"536106EA.5090204@xiplink.com","subject":"RE: Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-30T16:47:02Z","receivedAt":"2014-04-30T16:47:02Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Marc Branchaud wrote:\n> But I'm definitely biased because I think pull is pretty much broken:\n> \n> * New users are encouraged to use pull, but all too often the default\n> fetch-then-merge behaviour doesn't match their expectations and they end up\n> starting threads like this one on the mailing list.\n\nYes, this has been discussed many times in the past, and everyone agrees\nthe default behavior is not correct.\n\nMost people agree it has to be changed.\n\nAnd we have patches for it[1].\n\nBut it's not going to change. Why? No reason given, it's just not going\nto.\n\n> * If we change pull's default behaviour, we'll just be shifting the\n> mismatched expectations onto the other half of the new users who would be\n> happy with fetch-then-merge.\n\nNot true. As it has been agreed in the discussions, very few people\nwould be affected negatively by this change, and even then an\nappropriate error message like:\n\n The pull was not fast-forward, please either merge or rebase.\n If unsure, run 'git pull --merge'.\n\nShould do the trick.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/247567\n\n-- \nFelipe Contreras\n"},{"id":"240336","messageId":"vpqha5akamh.fsf@anie.imag.fr","threadId":"36513","inReplyTo":"536129068cc28_1404fdd310fd@nysa.notmuch","subject":"Re: Pull is Evil","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-04-30T17:09:10Z","receivedAt":"2014-04-30T17:09:10Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Felipe Contreras writes:\n\n> Marc Branchaud wrote:\n>> But I'm definitely biased because I think pull is pretty much broken:\n>> \n>> * New users are encouraged to use pull, but all too often the default\n>> fetch-then-merge behaviour doesn't match their expectations and they end up\n>> starting threads like this one on the mailing list.\n>\n> Yes, this has been discussed many times in the past, and everyone agrees\n> the default behavior is not correct.\n\nYou definitely have a strange notion of \"everyone\".\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"240343","messageId":"5BA0AC67-CDD6-4725-B75D-B98F957EB51E@mac.com","threadId":"36513","inReplyTo":"4ay6w9i74cygt6ii1b0db7wg.1398433713382@email.android.com","subject":"Re: A failing attempt to use Git in a centralized environment","fromName":"Geert Bosch","fromEmail":"boschg@mac.com","sentAt":"2014-04-30T17:15:30Z","receivedAt":"2014-04-30T17:15:30Z","isPatch":false,"sender":{"key":"boschg@mac.com","avatar":null},"body":"\nOn Apr 28, 2014, at 02:29, Marat Radchenko wrote:\n\n> In short:\n> 1. Hack, hack, hack\n> 2. Commit\n> 3. Push, woops, reject (non-ff)\n> 4. Pull\n> 5. Push\n\nJust do pull --rebase? This is essentially the same as what SVN\nused to do in your setup.\n\n -Geert\n"},{"id":"240347","messageId":"5361416a172fe_f9b15012ec7e@nysa.notmuch","threadId":"36513","inReplyTo":"vpqha5akamh.fsf@anie.imag.fr","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-30T18:31:06Z","receivedAt":"2014-04-30T18:31:06Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Matthieu Moy wrote:\n> Felipe Contreras writes:\n> \n> > Marc Branchaud wrote:\n> >> But I'm definitely biased because I think pull is pretty much broken:\n> >> \n> >> * New users are encouraged to use pull, but all too often the default\n> >> fetch-then-merge behaviour doesn't match their expectations and they end up\n> >> starting threads like this one on the mailing list.\n> >\n> > Yes, this has been discussed many times in the past, and everyone agrees\n> > the default behavior is not correct.\n> \n> You definitely have a strange notion of \"everyone\".\n\nDo I? Let's look at some of the discussions:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/225146\n\n* W. Trevor King agrees the default should change\n* Junio C Hamano agrees the default should change\n* John Keeping agrees the default should change\n* Matthieu Moy doesn't agree anything should change\n* Linus Torvalds agrees changing the default is fine\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/233554\n\n* Richard Hansen agrees with my proposal\n* Ramkumar Ramachandra agrees with my proposal\n* Brian M. Carlson is not happy but can live with my proposal\n* Jeff King accepts my proposal is a good way to move forward\n* Matthieu Moy is OK with change, but only if the default remains the same\n\nSo, by \"everyone\" I mean everyone but one person (you).\n\nRational people don't think in absolute terms, \"everyone\" means\nvirtually everyone, which is the case.\n\n-- \nFelipe Contreras\n"},{"id":"240349","messageId":"xmqq38gufxbm.fsf@gitster.dls.corp.google.com","threadId":"36513","inReplyTo":"5361416a172fe_f9b15012ec7e@nysa.notmuch","subject":"Re: Pull is Evil","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-30T19:10:05Z","receivedAt":"2014-04-30T19:10:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Matthieu Moy wrote:\n>> Felipe Contreras writes:\n>> ...\n>> > Yes, this has been discussed many times in the past, and everyone agrees\n>> > the default behavior is not correct.\n>> \n>> You definitely have a strange notion of \"everyone\".\n>\n> Do I? Let's look at some of the discussions:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/225146\n>\n> * W. Trevor King agrees the default should change\n> * Junio C Hamano agrees the default should change\n> * John Keeping agrees the default should change\n> * Matthieu Moy doesn't agree anything should change\n> * Linus Torvalds agrees changing the default is fine\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/233554\n>\n> * Richard Hansen agrees with my proposal\n> * Ramkumar Ramachandra agrees with my proposal\n> * Brian M. Carlson is not happy but can live with my proposal\n> * Jeff King accepts my proposal is a good way to move forward\n> * Matthieu Moy is OK with change, but only if the default remains the same\n>\n> So, by \"everyone\" I mean everyone but one person (you).\n\nI looked at the latter thread and re-read what Peff wrote (added to\nCc). I think the most relevant (other than solving it in quite a\ndifferent way $gmane/233554) one to your version of the solution is\nthis:\n\n http://thread.gmane.org/gmane.comp.version-control.git/233554/focus=234365\n\nwhere he responds to my \"how about this way forward\" with this:\n\n > ... I think other people are also in\n > agreement. So perhaps:\n > \n > - drop jc/pull-training-wheel and revert its merge from 'next';\n > \n > - update Felipe's series with a bit of tweak to make it less\n > impactful by demoting error into warning and advice.\n > \n > would be a good way forward?\n\n I think that would address the concern I raised, because it does not\n create a roadblock to new users accomplishing their task. They can\n ignore the warning, or choose \"merge\" as the default to shut up the\n warning (and it is easy to choose that if you are confused, because\n it is what git is doing by default alongside the warning).\n\nWhile I do not quite see the previous discussion as deciding the\nparticular implementation is good without further tweaks, I would\nsay that everybody agrees that the default behaviour is not good for\neverybody and therefore should (or for Linus, \"it is OK to\") change.\n\n> Rational people don't think in absolute terms, \"everyone\" means\n> virtually everyone, which is the case.\n\nTrue for \"should change\", not virtually everyone for \"should change\nwith that particular solution\".\n\nBut after re-reading the series description 0/n this round in the\nother thread, I think the overall direction is good (just like Peff\nsaid in the previous thread), especially if there is a warning not\nerror period.\n\nThe step (I am not sure you have it in your series or not, but I\nwould strongly recommend adding one if it doesn't yet) that gives a\n\"will change the default, and here is how to configure\" warning when\nwe see an actual merge made (or rebased) after \"git pull\" without\n\"--merge/--rebase\" is not just a way to prepare existing users, but\nis a good way to bring new goodness to newbies. The session might\ngo like this:\n\n\t$ git pull\n ... fetching ...\n ... merging ...\n ... diffstat ...\n warning: you merged the $branch from $remote into your\n warning: work, which may not be what you wanted to do unless\n warning: you are acting as a project integrator. If that is\n warning: the case, \"git config --set pull.mode ff-only\" to\n warning: cause \"git pull\" to refuse working when it does not\n warning: fast-forward. Use pull.mode=merge if you did mean\n warning: it, to squelch this message.\n\nI am not advocating the exact wording above, but am illustrating\nthat there is a place for us to tell the new people to live in a\nbetter future before the switchover happens.\n"},{"id":"240354","messageId":"53614fb5e204_2aa5fa32f0df@nysa.notmuch","threadId":"36513","inReplyTo":"xmqq38gufxbm.fsf@gitster.dls.corp.google.com","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-30T19:32:05Z","receivedAt":"2014-04-30T19:32:05Z","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> > Matthieu Moy wrote:\n> >> Felipe Contreras writes:\n> >> ...\n> >> > Yes, this has been discussed many times in the past, and everyone agrees\n> >> > the default behavior is not correct.\n> >> \n> >> You definitely have a strange notion of \"everyone\".\n\n> While I do not quite see the previous discussion as deciding the\n> particular implementation is good without further tweaks, I would\n> say that everybody agrees that the default behaviour is not good for\n> everybody and therefore should (or for Linus, \"it is OK to\") change.\n\nYes. The only aspect I didn't see consensus is whether\n'git pull $remote' should reject non-ff merges by default as well. I\nargued that 'git pull $remote' shouldn't behave differently than\n'git pull', but I got no responses.\n\n> > Rational people don't think in absolute terms, \"everyone\" means\n> > virtually everyone, which is the case.\n> \n> True for \"should change\", not virtually everyone for \"should change\n> with that particular solution\".\n\nI said 'everyone agrees the default behavior is not correct', which is\ntrue.\n\n> But after re-reading the series description 0/n this round in the\n> other thread, I think the overall direction is good (just like Peff\n> said in the previous thread), especially if there is a warning not\n> error period.\n> \n> The step (I am not sure you have it in your series or not, but I\n> would strongly recommend adding one if it doesn't yet) that gives a\n> \"will change the default, and here is how to configure\" warning when\n> we see an actual merge made (or rebased) after \"git pull\" without\n> \"--merge/--rebase\" is not just a way to prepare existing users, but\n> is a good way to bring new goodness to newbies. The session might\n> go like this:\n> \n> \t$ git pull\n> ... fetching ...\n> ... merging ...\n> ... diffstat ...\n> warning: you merged the $branch from $remote into your\n> warning: work, which may not be what you wanted to do unless\n> warning: you are acting as a project integrator. If that is\n> warning: the case, \"git config --set pull.mode ff-only\" to\n> warning: cause \"git pull\" to refuse working when it does not\n> warning: fast-forward. Use pull.mode=merge if you did mean\n> warning: it, to squelch this message.\n> \n> I am not advocating the exact wording above, but am illustrating\n> that there is a place for us to tell the new people to live in a\n> better future before the switchover happens.\n\nAs I said, I already sent a patch similar to that, but I dropped it\nsince this was for v2.0, and since I excepted this series to be ignored\nlike so many.\n\nI'll resend.\n\n-- \nFelipe Contreras\n"},{"id":"240356","messageId":"536152D3.5050107@xiplink.com","threadId":"36513","inReplyTo":"xmqqppjyhnom.fsf@gitster.dls.corp.google.com","subject":"Re: Pull is Evil","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2014-04-30T19:45:23Z","receivedAt":"2014-04-30T19:45:23Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 14-04-30 10:55 AM, Junio C Hamano wrote:\n> Marc Branchaud writes:\n> \n>> But I'm definitely biased because I think pull is pretty much broken:\n>>\n>> * New users are encouraged to use pull, but all too often the default\n>> fetch-then-merge behaviour doesn't match their expectations and they end up\n>> starting threads like this one on the mailing list.\n>>\n>> * If we change pull's default behaviour, we'll just be shifting the\n>> mismatched expectations onto the other half of the new users who would be\n>> happy with fetch-then-merge.\n>>\n>> * I'm not sure why new users are taught to use pull. I suspect it's because\n>> it tries to hide the idea of local-vs-remote branches, and people writing git\n>> tutorials don't want to overwhelm new users with what seems to be an internal\n>> detail. But these notions are really fundamental to using git effectively,\n>> and I think pull does everyone a disservice by trying to gloss them over.\n>>\n>> Anyway, rather than ranting on I'll just suggest that there's not enough\n>> commonality between the ways people use git to make it worthwhile trying to\n>> teach pull how to deal with a significant number of them. I think the pull\n>> command should be deprecated and quietly retired as a failed experiment.\n> \n> I almost agree with the first sentence in the last paragraph, and\n> your bulletted list above supports it.\n> \n> I am not sure how the second sentence can follow as its consequence.\n> \n> If the conclusion were \"maybe adding a 'git update' to match the\n> expectation of those who build on top of the work of others (aka\n> CVS/SVN style) more closely and teaching new users to use that\n> instead of 'git pull' may be a good way forward\", I can sort of\n> understand (if I may not be able to immediately agree with, until I\n> can regurgitate the ramifications of such a change) it.\n\n(Yum! You know, regurgitated ramifications aren't just for breakfast\nanymore... :) )\n\nI think we would run into much the same problem with \"git update\" as we do\nwith \"git pull\". To wit, any \"git pull\" (or \"git update\") implementation\nneeds to make certain workflow assumptions. I think that no matter which\nassumptions are made, there will always be a significant proportion of new\nusers[1] for whom the assumptions are wrong.\n\nThis is why the command is broken. It's also why the \"let's change git pull\"\ndiscussions never seem to get anywhere: Attempting to make the command work\nin new user X's environment will make it not work in new user Y's. Whatever\nchange is made to \"git pull\", after a few months new user Y comes along and\nsays it's wrong.\n\nAnd now we're seeing third-party tools, like TortoiseGit, using \"git pull\"\n(or the default \"git pull\" workflow model) and exposing yet more new users to\nworkflow dissonance.\n\nI don't think we'll ever be able to create a One \"Git Pull\" To Rule Them All.\n At best we'll end up with something with enough knobs that it could be\nconfigured to work in most workflows (I think we're actually pretty close to\nthat). But for new users that defeats the purpose. It means that \"git pull\"\nis really an advanced command, and beginners should avoid it until they\nunderstand enough of git to configure it properly.\n\nSo rather than perpetuate the myth that one command can always (or even just\nusually) do the right thing, let's just retire the command.\n\nAll that said, I don't object to any attempts at improving the command\neither. But I also don't see any kind of improvement that would lead me to\nstart using \"git pull\" let alone recommending it to new users.\n\n\t\tM.\n\n[1] By \"significant\" I mean \"enough to perpetually create new mailing list\nthreads about changing 'git pull'\".\n"},{"id":"240358","messageId":"xmqqlhumegqg.fsf@gitster.dls.corp.google.com","threadId":"36513","inReplyTo":"53614fb5e204_2aa5fa32f0df@nysa.notmuch","subject":"Re: Pull is Evil","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-30T19:53:43Z","receivedAt":"2014-04-30T19:53:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Junio C Hamano wrote:\n>> Felipe Contreras writes:\n>> > Matthieu Moy wrote:\n>> >> Felipe Contreras writes:\n>> >> ...\n>> >> > Yes, this has been discussed many times in the past, and everyone agrees\n>> >> > the default behavior is not correct.\n>> >> \n>> >> You definitely have a strange notion of \"everyone\".\n>\n>> While I do not quite see the previous discussion as deciding the\n>> particular implementation is good without further tweaks, I would\n>> say that everybody agrees that the default behaviour is not good for\n>> everybody and therefore should (or for Linus, \"it is OK to\") change.\n> ...\n> I said 'everyone agrees the default behavior is not correct', which is\n> true.\n\nIsn't that what I said a few lines above? Why are you still\narguing?\n"},{"id":"240363","messageId":"20140430200146.GU9218@google.com","threadId":"36513","inReplyTo":"536152D3.5050107@xiplink.com","subject":"Re: Pull is Evil","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-04-30T20:01:46Z","receivedAt":"2014-04-30T20:01:46Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Marc Branchaud wrote:\n\n> All that said, I don't object to any attempts at improving the command\n> either. But I also don't see any kind of improvement that would lead me to\n> start using \"git pull\" let alone recommending it to new users.\n\nIf \"git pull\" starts using --ff-only by default then I might start\nrecommending it.\n\nI'm a little scared to look at the details of this thread. Hopefully\nonce the topic matures and settles down a little it will be worthwhile\nto review, or if there's any way I can help before then, feel free to\nask me privately.\n\nThanks for your work,\nJonathan\n"},{"id":"240361","messageId":"xmqqa9b2egcy.fsf@gitster.dls.corp.google.com","threadId":"36513","inReplyTo":"536152D3.5050107@xiplink.com","subject":"Re: Pull is Evil","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-30T20:01:49Z","receivedAt":"2014-04-30T20:01:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n> On 14-04-30 10:55 AM, Junio C Hamano wrote:\n>> Marc Branchaud writes:\n> ...\n>>> Anyway, rather than ranting on I'll just suggest that there's not enough\n>>> commonality between the ways people use git to make it worthwhile trying to\n>>> teach pull how to deal with a significant number of them. I think the pull\n>>> command should be deprecated and quietly retired as a failed experiment.\n>> \n>> I almost agree with the first sentence in the last paragraph, and\n>> your bulletted list above supports it.\n>> \n>> I am not sure how the second sentence can follow as its consequence.\n>> \n>> If the conclusion were \"maybe adding a 'git update' to match the\n>> expectation of those who build on top of the work of others (aka\n>> CVS/SVN style) more closely and teaching new users to use that\n>> instead of 'git pull' may be a good way forward\", I can sort of\n>> understand (if I may not be able to immediately agree with, until I\n>> can regurgitate the ramifications of such a change) it.\n>\n> I think we would run into much the same problem with \"git update\" as we do\n> with \"git pull\"....\n\nMaybe I was unclear.\n\nI didn't mean \"replace 'pull' with 'update' everywhere\". I meant\n\"Introduce 'update' that lets integrate your history into that from\nthe remote, which is to integrate in a direction opposite from how\n'pull' does\". \n\nThen the downstream people (i.e. by definition, most of us) would\nuse \"git update\" while integrators would use \"git pull\". There is\nno workflow assumption if we do so.\n\n> I don't think we'll ever be able to create a One \"Git Pull\" To Rule Them All.\n\nYes, that is exactly why I mentioned \"git update\".\n\nAnother way not to make any workflow assumption is to ask the user\nto tell us.\n"},{"id":"240366","messageId":"536158f39fccd_4781124b2f090@nysa.notmuch","threadId":"36513","inReplyTo":"xmqqlhumegqg.fsf@gitster.dls.corp.google.com","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-30T20:11:31Z","receivedAt":"2014-04-30T20:11:31Z","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> > Junio C Hamano wrote:\n> >> Felipe Contreras writes:\n> >> > Matthieu Moy wrote:\n> >> >> Felipe Contreras writes:\n> >> >> ...\n> >> >> > Yes, this has been discussed many times in the past, and everyone agrees\n> >> >> > the default behavior is not correct.\n> >> >> \n> >> >> You definitely have a strange notion of \"everyone\".\n> >\n> >> While I do not quite see the previous discussion as deciding the\n> >> particular implementation is good without further tweaks, I would\n> >> say that everybody agrees that the default behaviour is not good for\n> >> everybody and therefore should (or for Linus, \"it is OK to\") change.\n> > ...\n> > I said 'everyone agrees the default behavior is not correct', which is\n> > true.\n> \n> Isn't that what I said a few lines above? Why are you still\n> arguing?\n\nI'm not arguing, I'm clarifying what I said for Matthieu. What I said\nwas a response to him.\n\n-- \nFelipe Contreras\n"},{"id":"240367","messageId":"5361598f8eaf7_4781124b2f02b@nysa.notmuch","threadId":"36513","inReplyTo":"536152D3.5050107@xiplink.com","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-30T20:14:07Z","receivedAt":"2014-04-30T20:14:07Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Marc Branchaud wrote:\n> All that said, I don't object to any attempts at improving the command\n> either. But I also don't see any kind of improvement that would lead\n> me to start using \"git pull\" let alone recommending it to new users.\n\nWhat is wrong when `git pull` merges a fast-forward? The problems with\n`git pull` come when you can't do a fast-forward merge, right?\n\n-- \nFelipe Contreras\n"},{"id":"240384","messageId":"53616FA2.2010405@xiplink.com","threadId":"36513","inReplyTo":"xmqqa9b2egcy.fsf@gitster.dls.corp.google.com","subject":"Re: Pull is Evil","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2014-04-30T21:48:18Z","receivedAt":"2014-04-30T21:48:18Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 14-04-30 04:01 PM, Junio C Hamano wrote:\n> \n> Maybe I was unclear.\n> \n> I didn't mean \"replace 'pull' with 'update' everywhere\". I meant\n> \"Introduce 'update' that lets integrate your history into that from\n> the remote, which is to integrate in a direction opposite from how\n> 'pull' does\". \n\nThat's what I understood.\n\n> Then the downstream people (i.e. by definition, most of us) would\n> use \"git update\" while integrators would use \"git pull\". There is\n> no workflow assumption if we do so.\n\nIsn't merge-or-rebase a workflow assumption? I don't think there's a good\nrule of thumb for that choice. Downstream-vs-Integrator doesn't seem like\nenough, nor does it seem as simple as \"'git pull' should merge\" and \"'git\nupdate' should rebase\" (or vice-versa).\n\nBut maybe I'm wrong and there really is only one salient axis (be it that one\nor another).\n\n>> I don't think we'll ever be able to create a One \"Git Pull\" To Rule Them All.\n> \n> Yes, that is exactly why I mentioned \"git update\".\n\nI doubt that a new, additional command with different workflow assumptions\nwill be any more successful.\n\n> Another way not to make any workflow assumption is to ask the user\n> to tell us.\n\nYes. But I wouldn't expect a new user to be able to answer.\n\n\t\tM.\n"},{"id":"240387","messageId":"536173F5.7010905@xiplink.com","threadId":"36513","inReplyTo":"5361598f8eaf7_4781124b2f02b@nysa.notmuch","subject":"Re: Pull is Evil","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2014-04-30T22:06:45Z","receivedAt":"2014-04-30T22:06:45Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 14-04-30 04:14 PM, Felipe Contreras wrote:\n> Marc Branchaud wrote:\n>> All that said, I don't object to any attempts at improving the command\n>> either. But I also don't see any kind of improvement that would lead\n>> me to start using \"git pull\" let alone recommending it to new users.\n> \n> What is wrong when `git pull` merges a fast-forward?\n\nNothing. Everything. It depends.\n\n> The problems with `git pull` come when you can't do a fast-forward merge, right?\n\nSome of them, maybe most of them.\n\nBut the reason \"git pull\" is broken is that any solution to the problems that\narise depend on the project's workflow. That would be fine if there was a\nworkflow that suited some large majority of users, but there doesn't seem to\nbe one.\n\n\n\n\t\tM.\n\n[1] https://www.survs.com/results/QPESOB10/ME8UTHXM4M\n"},{"id":"240391","messageId":"53617877b41a9_41a872f308ef@nysa.notmuch","threadId":"36513","inReplyTo":"536173F5.7010905@xiplink.com","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-04-30T22:25:59Z","receivedAt":"2014-04-30T22:25:59Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Marc Branchaud wrote:\n> On 14-04-30 04:14 PM, Felipe Contreras wrote:\n> > Marc Branchaud wrote:\n> >> All that said, I don't object to any attempts at improving the command\n> >> either. But I also don't see any kind of improvement that would lead\n> >> me to start using \"git pull\" let alone recommending it to new users.\n> > \n> > What is wrong when `git pull` merges a fast-forward?\n> \n> Nothing. Everything. It depends.\n\nIt depends on what? I don't see how a fast-forward `git pull` could\npossibly have any trouble.\n\n> > The problems with `git pull` come when you can't do a fast-forward merge, right?\n> \n> Some of them, maybe most of them.\n\nName one problem with a fast-forward merge.\n\n-- \nFelipe Contreras\n"},{"id":"240398","messageId":"20140501094610.GB75770@vauxhall.crustytoothpaste.net","threadId":"36513","inReplyTo":"53617877b41a9_41a872f308ef@nysa.notmuch","subject":"Re: Pull is Evil","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2014-05-01T09:46:10Z","receivedAt":"2014-05-01T09:46:10Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:\n> Marc Branchaud wrote:\n> > On 14-04-30 04:14 PM, Felipe Contreras wrote:\n> > > What is wrong when `git pull` merges a fast-forward?\n> > \n> > Nothing. Everything. It depends.\n> \n> It depends on what? I don't see how a fast-forward `git pull` could\n> possibly have any trouble.\n> \n> > > The problems with `git pull` come when you can't do a fast-forward merge, right?\n> > \n> > Some of them, maybe most of them.\n> \n> Name one problem with a fast-forward merge.\n\nAt work, we have a workflow where we merge topic branches as\nnon-fast-forward, so that we have a record of the history (including who\nreviewed the code), but when we want to just update our local branches,\nwe always want fast-forward:\n\n git checkout maintenance-branch\n # Update our maintenance branch to the latest from the main repo.\n git pull --ff-only\n git pull --no-ff developer-remote topic-branch\n git push main-repo HEAD\n\nSo there are times when fast-forward merges are the right thing, and\ntimes when they're not, and as you can see, this depends on context and\nisn't per-repository.\n\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"240399","messageId":"5362266a3ca00_284da2f2eca3@nysa.notmuch","threadId":"36513","inReplyTo":"20140501094610.GB75770@vauxhall.crustytoothpaste.net","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-01T10:48:10Z","receivedAt":"2014-05-01T10:48:10Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"brian m. carlson wrote:\n> On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:\n> > Marc Branchaud wrote:\n> > > On 14-04-30 04:14 PM, Felipe Contreras wrote:\n> > > > What is wrong when `git pull` merges a fast-forward?\n> > > \n> > > Nothing. Everything. It depends.\n> > \n> > It depends on what? I don't see how a fast-forward `git pull` could\n> > possibly have any trouble.\n> > \n> > > > The problems with `git pull` come when you can't do a fast-forward merge, right?\n> > > \n> > > Some of them, maybe most of them.\n> > \n> > Name one problem with a fast-forward merge.\n> \n> At work, we have a workflow where we merge topic branches as\n> non-fast-forward, so that we have a record of the history (including who\n> reviewed the code), but when we want to just update our local branches,\n> we always want fast-forward:\n> \n> git checkout maintenance-branch\n> # Update our maintenance branch to the latest from the main repo.\n> git pull --ff-only\n> git pull --no-ff developer-remote topic-branch\n> git push main-repo HEAD\n> \n> So there are times when fast-forward merges are the right thing, and\n> times when they're not, and as you can see, this depends on context and\n> isn't per-repository.\n\nThat's not what I asked.\n\nI didn't ask you if fast-forward merges were the right thing to do in\nevery situation.\n\nI asked you, *when* people do a fast-forward merge (that is; when it's\npossible and desirable), what are the problems that a fast-forward merge\ncauses?\n\nI tired of waiting, so I'll answer for you: there are absolutely no\nproblems. The problems are only on non-fast-forward merges, and we have\na solution.\n\n-- \nFelipe Contreras\n"},{"id":"240406","messageId":"7vbnvhil5x.fsf@alter.siamese.dyndns.org","threadId":"36513","inReplyTo":"5362266a3ca00_284da2f2eca3@nysa.notmuch","subject":"Re: Pull is Evil","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-01T15:16:42Z","receivedAt":"2014-05-01T15:16:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> brian m. carlson wrote:\n>> ..\n>> At work, we have a workflow where we merge topic branches as\n>> non-fast-forward, so that we have a record of the history (including who\n>> reviewed the code), but when we want to just update our local branches,\n>> we always want fast-forward:\n>> \n>> git checkout maintenance-branch\n>> # Update our maintenance branch to the latest from the main repo.\n>> git pull --ff-only\n>> git pull --no-ff developer-remote topic-branch\n>> git push main-repo HEAD\n>> \n>> So there are times when fast-forward merges are the right thing, and\n>> times when they're not, and as you can see, this depends on context and\n>> isn't per-repository.\n>\n> That's not what I asked.\n>\n> I didn't ask you if fast-forward merges were the right thing to do in\n> every situation.\n>\n> I asked you, *when* people do a fast-forward merge (that is; when it's\n> possible and desirable), what are the problems that a fast-forward merge\n> causes?\n\nBut then I think you asked a wrong question. The opposite case of\nthe question tells me what is wrong in it:\n\n When people do a real merge (that is: when it's possible and\n desirable), there is no reason to forbid 'git pull' from creating a\n real merge. What are the problems that a real merge causes under\n that condition?\n\nBy definition, because of \"when it's possible and DESIRABLE\" part,\nthe answer is \"absolutely zero\". That is not an interesting\nquestion, is it?\n\nMy reading of the design of the \"let's forbid non-ff merge when\npeople do 'git pull'\" is based on this reasonong:\n\n - Most people are not integrators, and letting \"git pull\" run on\n their work based on a stale upstream to sync with an updated\n upstream would create a merge in a wrong direction and letting\n user continue on it. We need to have a way to prevent this.\n\n - Forbid \"git pull\" when the HEAD is based on a stale upstream,\n i.e. the pull does not fast-forward. Integrators that would want\n to _allow_ real merges may be inconvenienced so we will give a\n configuration to let them say that with pull.mode=merge.\n\n - We do not forbid \"git pull\" if the pull will fast-forward. We do\n not do anything for that case, because everybody will accept\n fast-forward, whether he is a contributor or an integrator.\n\nDoesn't Brian's case show the justification \"because everybody will\naccept fast-forward\" does not hold? It shows that the user do not\nnecessarily know when it's possible and DESIRABLE, and updating the\ncommand is about helping people avoid an action that may not be\ndesirable in the end.\n\nBrian needs a way to make sure he fast-forwards when pulling the\nproject's maintenance-branch into his maintenance-branch, and also\nhe does *not* fast-forward when pulling developer's fix branch into\nthat same maintenance-branch of his. So neither pull.mode nor\nbranch.*.pullmode would help him and the example may show we need a\nbit more work to help that case, no?\n"},{"id":"240405","messageId":"5362664C.8040907@xiplink.com","threadId":"36513","inReplyTo":"20140501094610.GB75770@vauxhall.crustytoothpaste.net","subject":"Re: Pull is Evil","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2014-05-01T15:20:44Z","receivedAt":"2014-05-01T15:20:44Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 14-05-01 05:46 AM, brian m. carlson wrote:\n> On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:\n>> Marc Branchaud wrote:\n>>> On 14-04-30 04:14 PM, Felipe Contreras wrote:\n>>>> What is wrong when `git pull` merges a fast-forward?\n>>>\n>>> Nothing. Everything. It depends.\n>>\n>> It depends on what? I don't see how a fast-forward `git pull` could\n>> possibly have any trouble.\n>>\n>>>> The problems with `git pull` come when you can't do a fast-forward merge, right?\n>>>\n>>> Some of them, maybe most of them.\n>>\n>> Name one problem with a fast-forward merge.\n> \n> At work, we have a workflow where we merge topic branches as\n> non-fast-forward, so that we have a record of the history (including who\n> reviewed the code), but when we want to just update our local branches,\n> we always want fast-forward:\n> \n> git checkout maintenance-branch\n> # Update our maintenance branch to the latest from the main repo.\n> git pull --ff-only\n> git pull --no-ff developer-remote topic-branch\n> git push main-repo HEAD\n\nThanks for the nice example.\n\nTo me this looks like an advanced use of \"git pull\". A new user could be\ntaught to work like this, but I don't think a new user would come up with it\non their own (until they became an experienced user).\n\nWhat's more, it seems to me that the only real advantage \"git pull\" provides\nhere is a less typing compared to the non-pull 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\nI suggest that this approach is superior for new users (despite the increased\nrisk of finger cramps), because if main-repo's maintenance-branch is updated\nin the interim and the push fails, the user can use the exact same commands\nto resolve the situation.\n\nSure, the non-pull approach makes use of Scary Branch Stuff (remotes and\nnamespaces and detached HEADs -- oh my!). But trying to avoid that stuff is\nprecisely the slippery slope that led to pull's misguided gymnastics. We've\ngone down that slope, slipped and fallen over, and now we're wallowing in the\nmuck.\n\n\t\tM.\n"},{"id":"240409","messageId":"20140501175623.GY6227@odin.tremily.us","threadId":"36513","inReplyTo":"5362664C.8040907@xiplink.com","subject":"Re: Re: Pull is Evil","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-05-01T17:56:23Z","receivedAt":"2014-05-01T17:56:23Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:\n> On 14-05-01 05:46 AM, brian m. carlson wrote:\n> > git checkout maintenance-branch\n> > # Update our maintenance branch to the latest from the main repo.\n> > git pull --ff-only\n> > git pull --no-ff developer-remote topic-branch\n> > git push main-repo HEAD\n> \n> …\n> What's more, it seems to me that the only real advantage \"git pull\" provides\n> here is a less typing compared to the non-pull 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\nYou're missing Brian's fast-forward merge here. It should be:\n\n git checkout maintenance-branch\n git fetch main-repo\n git merge --ff-only main-repo/maintenance-branch\n git fetch developer-remote\n …\n\n> Sure, the non-pull approach makes use of Scary Branch Stuff (remotes\n> and namespaces and detached HEADs -- oh my!).\n\nNo need for detached heads with Brian's local maintenance-branch. If\nyou're teaching and just need folks merging the remote's HEAD, you\ncan avoid namespaces and remotes entirely:\n\n git fetch git://example.net/main-repo.git\n git merge --ff-only FETCH_HEAD\n\nalthough I doubt “the remote's HEAD” will be easier to explain than\nthe namespaced, remote-tracking branches it replaces. It's certainly\nnot worth the hassle of un-training FETCH_HEAD-merges later on ;).\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"240411","messageId":"53628CB1.8010302@xiplink.com","threadId":"36513","inReplyTo":"20140501175623.GY6227@odin.tremily.us","subject":"Re: Re: Pull is Evil","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2014-05-01T18:04:33Z","receivedAt":"2014-05-01T18:04:33Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 14-05-01 01:56 PM, W. Trevor King wrote:\n> On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:\n>> On 14-05-01 05:46 AM, brian m. carlson wrote:\n>>> git checkout maintenance-branch\n>>> # Update our maintenance branch to the latest from the main repo.\n>>> git pull --ff-only\n>>> git pull --no-ff developer-remote topic-branch\n>>> git push main-repo HEAD\n>>\n>> …\n>> What's more, it seems to me that the only real advantage \"git pull\" provides\n>> here is a less typing compared to the non-pull 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> You're missing Brian's fast-forward merge here. It should be:\n> \n> git checkout maintenance-branch\n> git fetch main-repo\n> git merge --ff-only main-repo/maintenance-branch\n> git fetch developer-remote\n> …\n\nI think you're mistaken -- I checked out \"main-repo/maintenance-branch\"\ndirectly, so there's no need to fast-forward a local branch.\n\n>> Sure, the non-pull approach makes use of Scary Branch Stuff (remotes\n>> and namespaces and detached HEADs -- oh my!).\n> \n> No need for detached heads with Brian's local maintenance-branch.\n\nYes. OTOH, no need to bother keeping a local maintenance-branch up to date\nif you use a detached HEAD.\n\n> If\n> you're teaching and just need folks merging the remote's HEAD, you\n> can avoid namespaces and remotes entirely:\n> \n> git fetch git://example.net/main-repo.git\n> git merge --ff-only FETCH_HEAD\n> \n> although I doubt “the remote's HEAD” will be easier to explain than\n> the namespaced, remote-tracking branches it replaces. It's certainly\n> not worth the hassle of un-training FETCH_HEAD-merges later on ;).\n\nAgreed. I wouldn't advocate teaching people about FETCH_HEAD as if it were\nsomething they should use regularly.\n\n\t\tM.\n"},{"id":"240425","messageId":"20140501183008.GZ6227@odin.tremily.us","threadId":"36513","inReplyTo":"53628CB1.8010302@xiplink.com","subject":"Re: Re: Pull is Evil","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-05-01T18:30:08Z","receivedAt":"2014-05-01T18:30:08Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, May 01, 2014 at 02:04:33PM -0400, Marc Branchaud wrote:\n> On 14-05-01 01:56 PM, W. Trevor King wrote:\n> > On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:\n> >> On 14-05-01 05:46 AM, brian m. carlson wrote:\n> >>> git checkout maintenance-branch\n> >>> # Update our maintenance branch to the latest from the main repo.\n> >>> git pull --ff-only\n> >>> git pull --no-ff developer-remote topic-branch\n> >>> git push main-repo HEAD\n> >>\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> > You're missing Brian's fast-forward merge here. It should be:\n> > \n> > git checkout maintenance-branch\n> > git fetch main-repo\n> > git merge --ff-only main-repo/maintenance-branch\n> > git fetch developer-remote\n> > …\n> \n> I think you're mistaken -- I checked out\n> \"main-repo/maintenance-branch\" directly, so there's no need to\n> fast-forward a local branch.\n\nI find a local branch useful to mark the amount of the upstream branch\nthat I've reviewed. The reflog helps a bit, but I may go several\nfetches between reviews. For newbies, I recommend avoiding detached\nHEADs, where possible, so they don't have to rely on the reflog if\nthey accidentally commit and then checkout something else (ignoring\nGit's warning).\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"240420","messageId":"53629da233345_76612eb2f075@nysa.notmuch","threadId":"36513","inReplyTo":"7vbnvhil5x.fsf@alter.siamese.dyndns.org","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-01T19:16:50Z","receivedAt":"2014-05-01T19:16:50Z","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> > brian m. carlson wrote:\n> >> ..\n> >> At work, we have a workflow where we merge topic branches as\n> >> non-fast-forward, so that we have a record of the history (including who\n> >> reviewed the code), but when we want to just update our local branches,\n> >> we always want fast-forward:\n> >> \n> >> git checkout maintenance-branch\n> >> # Update our maintenance branch to the latest from the main repo.\n> >> git pull --ff-only\n> >> git pull --no-ff developer-remote topic-branch\n> >> git push main-repo HEAD\n> >> \n> >> So there are times when fast-forward merges are the right thing, and\n> >> times when they're not, and as you can see, this depends on context and\n> >> isn't per-repository.\n> >\n> > That's not what I asked.\n> >\n> > I didn't ask you if fast-forward merges were the right thing to do in\n> > every situation.\n> >\n> > I asked you, *when* people do a fast-forward merge (that is; when it's\n> > possible and desirable), what are the problems that a fast-forward merge\n> > causes?\n> \n> But then I think you asked a wrong question.\n\nI asked the simple uncontroversial question as a rhetorical aid. I hoped\nI would get the obvious answer, but I didn't even get that, so what hope\nis there of convincing these people of the one that needs real pondering?\n\n> The opposite case of the question tells me what is wrong in it:\n> \n> When people do a real merge (that is: when it's possible and\n> desirable), there is no reason to forbid 'git pull' from creating a\n> real merge. What are the problems that a real merge causes under\n> that condition?\n> \n> By definition, because of \"when it's possible and DESIRABLE\" part,\n> the answer is \"absolutely zero\". That is not an interesting\n> question, is it?\n\nThat's right, but we are discussing the default behavior of `git pull`,\nwhich if we agree has no problems when the ff is a) possible, and b)\ndesirable, the problems must come when either one of those is not met.\n\n a) If the fast-forward is not possible, that creates problems, because\n a real merge might happen, and it's not desirable. However, if we\n don't allow real merges to happen by default this couldn't be a\n problem.\n\n b) If the fast-forward is not desirable, then the user wouldn't be\n running `git pull`, would be running `git pull --no-ff`.\n\nIn other words, after the proposed changes `git pull` by default would\nhave no issues.\n\n> Doesn't Brian's case show the justification \"because everybody will\n> accept fast-forward\" does not hold? It shows that the user do not\n> necessarily know when it's possible and DESIRABLE, and updating the\n> command is about helping people avoid an action that may not be\n> desirable in the end.\n\nNo, it doesn't hold. As I said, if we change the default the fact that\nit's not possible is not an issue.\n\nThe only problem would be when it's not desirable, however, that's a\nproblem of the user's ignorance, and the failure of the project's\npolicity to communicate clearly to him that he should be running\n`git merge --no-ff`. There's absolutely nothing we can do to help him.\n\nThe only thing we could do is not allow fast-forward merges either, in\nwhich case `git pull` becomes a no-op that can't possibly do anything\never.\n\n> Brian needs a way to make sure he fast-forwards when pulling the\n> project's maintenance-branch into his maintenance-branch, and also he\n> does *not* fast-forward when pulling developer's fix branch into that\n> same maintenance-branch of his.\n\nFirst of all this use-case is not realistic. The moment he merges a\ndeveloper branch, hes maintenance and the probject's diverge, and all\nthe pulls after that cannot be fast-forward.\n\nIt's pointless to add something that just doesn't happen. It will be\npossible to do the fast-forward merges only early on the life of this\nbranch, not afterwards. For this short period of time he can just simply\nuse his fingers to type `git merge --no-ff`.\n\n-- \nFelipe Contreras\n"},{"id":"240421","messageId":"53629eda40a52_76612eb2f062@nysa.notmuch","threadId":"36513","inReplyTo":"5362664C.8040907@xiplink.com","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-01T19:22:02Z","receivedAt":"2014-05-01T19:22:02Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Marc Branchaud wrote:\n> What's more, it seems to me that the only real advantage \"git pull\"\n> provides here is a less typing compared to the non-pull 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\nYou mean `git push main-repo HEAD:maintenance-branch`, right?\n\n-- \nFelipe Contreras\n"},{"id":"240422","messageId":"5362a02f5a153_76612eb2f071@nysa.notmuch","threadId":"36513","inReplyTo":"20140501094610.GB75770@vauxhall.crustytoothpaste.net","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-01T19:27:43Z","receivedAt":"2014-05-01T19:27:43Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"brian m. carlson wrote:\n> At work, we have a workflow where we merge topic branches as\n> non-fast-forward, so that we have a record of the history (including\n> who reviewed the code), but when we want to just update our local\n> branches, we always want fast-forward:\n> \n> git checkout maintenance-branch\n> # Update our maintenance branch to the latest from the main repo.\n> git pull --ff-only\n\nIf we make it the default, you only need to type `git pull`.\n\n> git pull --no-ff developer-remote topic-branch\n\nI don't see anything wrong with having to type --no-ff if that's what\nyou really want.\n\n> git push main-repo HEAD\n\nmain-repo/maintenance-branch should be the upstream of\nmaintenance-branch, in which hase:\n\n% git push\n\n-- \nFelipe Contreras\n"},{"id":"240423","messageId":"5362A3CB.5020203@xiplink.com","threadId":"36513","inReplyTo":"53629eda40a52_76612eb2f062@nysa.notmuch","subject":"Re: Pull is Evil","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2014-05-01T19:43:07Z","receivedAt":"2014-05-01T19:43:07Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 14-05-01 03:22 PM, Felipe Contreras wrote:\n> Marc Branchaud wrote:\n>> What's more, it seems to me that the only real advantage \"git pull\"\n>> provides here is a less typing compared to the non-pull 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> You mean `git push main-repo HEAD:maintenance-branch`, right?\n\nRight. Sorry, for that command I thoughtlessly just copied Brian's example.\n\n\t\tM.\n"},{"id":"240424","messageId":"20140501194846.GA6227@odin.tremily.us","threadId":"36513","inReplyTo":"53629da233345_76612eb2f075@nysa.notmuch","subject":"Re: Re: Pull is Evil","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-05-01T19:48:47Z","receivedAt":"2014-05-01T19:48:47Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, May 01, 2014 at 02:16:50PM -0500, Felipe Contreras wrote:\n> The only problem would be when it's not desirable, however, that's a\n> problem of the user's ignorance, and the failure of the project's\n> policity to communicate clearly to him that he should be running\n> `git merge --no-ff`. There's absolutely nothing we can do to help him.\n\nI think “user ignorange” is the *only* problem with git pull. Once\nyou understand the ff flags, you can set them however you like, and\npull will do what you tell it to.\n\n> The only thing we could do is not allow fast-forward merges either, in\n> which case `git pull` becomes a no-op that can't possibly do anything\n> ever.\n\nMy interest in all of the proposed git-pull-training-wheel patches is\nthat they give users a way to set a finger-breaking configuration that\nmakes pull a no-op (or slows it down, like 'rm -i …'). Then folks who\ncompulsively run 'git pull' (e.g. because SVN habits die slowly) can\nset an option that gives them something to think about before going\nahead and running the pull anyway. The space in 'git pull' makes a\nshell-side:\n\n $ alias 'git pull'='echo \"try fetch/merge!\"'\n\nsolution unfeasible, and clobbering /usr/libexec/git-core/git-pull\nseems a bit extreme.\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"240426","messageId":"20140501200703.GB6227@odin.tremily.us","threadId":"36513","inReplyTo":"20140501194846.GA6227@odin.tremily.us","subject":"Re: Re: Pull is Evil","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-05-01T20:07:04Z","receivedAt":"2014-05-01T20:07:04Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote:\n> My interest in all of the proposed git-pull-training-wheel patches is\n> that they give users a way to set a finger-breaking configuration that\n> makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who\n> compulsively run 'git pull' (e.g. because SVN habits die slowly) can\n> set an option that gives them something to think about before going\n> ahead and running the pull anyway.\n\nActually, what do we think about an -i/--interactive flag (with an\nassociated pull.interactive boolean config to setup global/per-repo\ndefaults)? Then after the fetch, you'd get one of the following:\n\n Merge $count commits from $repository $refspec into $current_branch?\n Rebase $count commits from $current_branch onto $repository $refpec?\n Fast-forward $current_branch by $count commits to $repository $refpec?\n\nand have a chance to bail out if you saw:\n\n Merge 1003 commits from git://example.net/main.git master into my-feature?\n\nbecause you forgot which branch you were on.\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"240427","messageId":"5362ACD6.50505@xiplink.com","threadId":"36513","inReplyTo":"20140501183008.GZ6227@odin.tremily.us","subject":"Re: Re: Pull is Evil","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2014-05-01T20:21:42Z","receivedAt":"2014-05-01T20:21:42Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 14-05-01 02:30 PM, W. Trevor King wrote:\n> \n> I find a local branch useful to mark the amount of the upstream branch\n> that I've reviewed. The reflog helps a bit, but I may go several\n> fetches between reviews. For newbies, I recommend avoiding detached\n> HEADs, where possible, so they don't have to rely on the reflog if\n> they accidentally commit and then checkout something else (ignoring\n> Git's warning).\n\nAll sound practices that I think are perfectly fine.\n\nI may be mistaken, but I think \"git pull\" evolved to try to address the\ndetached-HEAD risk (at least in part). This risk was pretty real before the\nreflog came about (I'm under the impression -- and too lazy to check -- that\n\"git pull\" predates the reflog; please forgive me if I'm mis-perceiving the\ntimeline).\n\nBut these days there's hardly any risk to using a detached HEAD. Plus\nnowadays I think it's commonly accepted that using topic branches is a git\nbest practice. The notion of doing work on a generically-named branch like\n\"maint\" seems archaic.\n\nSo what benefit does \"git pull\" provide?\n\nIn your particular case, you're using \"git pull\" to help you track your\nreviews of the upstream branch. To me this seems more like you taking\nadvantage of a \"git pull\" side-effect than using the command as it is\nintended to be used. Certainly there are other ways that git can track this\nfor you. A simple, aliasable, \"git tag -f LastReviewPoint upstream/branch\"\nseems just as effective to me (but then, I'm not you).\n\n\t\tM.\n"},{"id":"240474","messageId":"E699B6CE8ADD46618D52F05DB8EF6F07@PhilipOakley","threadId":"36513","inReplyTo":"536152D3.5050107@xiplink.com","subject":"Re: Pull is Evil","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2014-05-01T21:06:17Z","receivedAt":"2014-05-01T21:06:17Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Marc Branchaud\" \nSent: Wednesday, April 30, 2014 8:45 PM\n[...]\n> I don't think we'll ever be able to create a One \"Git Pull\" To Rule \n> Them All.\n> At best we'll end up with something with enough knobs that it could be\n> configured to work in most workflows (I think we're actually pretty \n> close to\n> that). But for new users that defeats the purpose. It means that \n> \"git pull\"\n> is really an advanced command, and beginners should avoid it until \n> they\n> understand enough of git to configure it properly.\n>\n> So rather than perpetuate the myth that one command can always (or \n> even just\n> usually) do the right thing, let's just retire the command.\n>\n> All that said, I don't object to any attempts at improving the command\n> either. But I also don't see any kind of improvement that would lead \n> me to\n> start using \"git pull\" let alone recommending it to new users.\n>\n> M.\n>\n> [1] By \"significant\" I mean \"enough to perpetually create new mailing \n> list\n> threads about changing 'git pull'\".\n>\n[general reply to all, rather than to anyone in particular, using Marc's \nsummary]\n\nThe point that there is no easy solution to an updated default pull \naction that is right for everybody, straight out of the box, I think is \nnow fairly obvious, a summarised by Marc. I certainly avoid pull.\n\nMy 'solution', if it could be called that, would be that at the point of \nswitch over, after a period of release note warning and then code \nwarning, that the plain 'git pull' would not even do the no-ff, but \nwould simply refuse to do anything unless the user had explicitly set \nthe [new] config variable(s) to a value of _their_ choice. The message \ncould give guidance based on their old setting(s) and the new options as \nappropriate, i.e. if they have an old definitive setting then the new \nsetting may be an obvious one.\n\nDuring the warning period between the release cycles, we may have a two \nstep ramp up of the warning, where the first cycle allows users who have \nread the release notes to choose their new setting and it's auto \ndetected from there on, then in the second cycle Git detects the lack of \na setting and gives a warning prompt (just like the Git 2.0 warning), \nand finally the change over release makes a 'git pull' without a config \nsetting an error.\n\nI know that for some it's a phaff that appears to waste time (been \nthere, been that person), but it does allow the stragglers time to pick \nup the hints and not be too surprised, which will include many otherwise \nprofessional folks who just happen to have other priorities [e.g. this \nmessage typed from a Win XP machine!].\n\nThe approach does have a solid heritage, and avoids anyone (on the \ncoding side) having to decide on an initial default, when it should be a \nuser choice. Though I do agree with Filipe that the '--no-ff merge' \nwould probably be the least worst for the new user and likely be a \nsuitable 'if you don't know use this one' suggestion.\n\nPhilip\n-- \n"},{"id":"240475","messageId":"B662835E37564DC6A3029973AFDD702F@PhilipOakley","threadId":"36513","inReplyTo":"E699B6CE8ADD46618D52F05DB8EF6F07@PhilipOakley","subject":"Re: Pull is Evil","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2014-05-01T21:16:33Z","receivedAt":"2014-05-01T21:16:33Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Oops..\nFrom: \"Philip Oakley\" \n> From: \"Marc Branchaud\" \n> Sent: Wednesday, April 30, 2014 8:45 PM\n> [...]\n>> I don't think we'll ever be able to create a One \"Git Pull\" To Rule \n>> Them All.\n>> At best we'll end up with something with enough knobs that it could \n>> be\n>> configured to work in most workflows (I think we're actually pretty \n>> close to\n>> that). But for new users that defeats the purpose. It means that \n>> \"git pull\"\n>> is really an advanced command, and beginners should avoid it until \n>> they\n>> understand enough of git to configure it properly.\n>>\n>> So rather than perpetuate the myth that one command can always (or \n>> even just\n>> usually) do the right thing, let's just retire the command.\n>>\n>> All that said, I don't object to any attempts at improving the \n>> command\n>> either. But I also don't see any kind of improvement that would lead \n>> me to\n>> start using \"git pull\" let alone recommending it to new users.\n>>\n>> M.\n>>\n>> [1] By \"significant\" I mean \"enough to perpetually create new mailing \n>> list\n>> threads about changing 'git pull'\".\n>>\n> [general reply to all, rather than to anyone in particular, using \n> Marc's summary]\n>\n> The point that there is no easy solution to an updated default pull \n> action that is right for everybody, straight out of the box, I think \n> is now fairly obvious, a summarised by Marc. I certainly avoid pull.\n>\n> My 'solution', if it could be called that, would be that at the point \n> of switch over, after a period of release note warning and then code \n> warning, that the plain 'git pull' would not even do the no-ff, but\n\ns/no-ff/--ff/g that is, only 'merge' if it's a fast forward.\n\n> would simply refuse to do anything unless the user had explicitly set \n> the [new] config variable(s) to a value of _their_ choice. The message \n> could give guidance based on their old setting(s) and the new options \n> as appropriate, i.e. if they have an old definitive setting then the \n> new setting may be an obvious one.\n>\n> During the warning period between the release cycles, we may have a \n> two step ramp up of the warning, where the first cycle allows users \n> who have read the release notes to choose their new setting and it's \n> auto detected from there on, then in the second cycle Git detects the \n> lack of a setting and gives a warning prompt (just like the Git 2.0 \n> warning), and finally the change over release makes a 'git pull' \n> without a config setting an error.\n>\n> I know that for some it's a phaff that appears to waste time (been \n> there, been that person), but it does allow the stragglers time to \n> pick up the hints and not be too surprised, which will include many \n> otherwise professional folks who just happen to have other priorities \n> [e.g. this message typed from a Win XP machine!].\n>\n> The approach does have a solid heritage, and avoids anyone (on the \n> coding side) having to decide on an initial default, when it should be \n> a user choice. Though I do agree with Filipe that the '--no-ff merge'\n\ns/no-ff/--ff/\n\n> would probably be the least worst for the new user and likely be a \n> suitable 'if you don't know use this one' suggestion.\n>\n> Philip\n> -- \nsorry for the finger-brain failures. \n"},{"id":"240484","messageId":"5362d6bbbf707_12fe14dd310ab@nysa.notmuch","threadId":"36513","inReplyTo":"20140501194846.GA6227@odin.tremily.us","subject":"Re: Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-01T23:20:27Z","receivedAt":"2014-05-01T23:20:27Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"W. Trevor King wrote:\n> On Thu, May 01, 2014 at 02:16:50PM -0500, Felipe Contreras wrote:\n> > The only problem would be when it's not desirable, however, that's a\n> > problem of the user's ignorance, and the failure of the project's\n> > policity to communicate clearly to him that he should be running\n> > `git merge --no-ff`. There's absolutely nothing we can do to help him.\n> \n> I think “user ignorange” is the *only* problem with git pull.\n\nThat, and the fact that 'git pull' does something wrong by default.\n\n> > The only thing we could do is not allow fast-forward merges either, in\n> > which case `git pull` becomes a no-op that can't possibly do anything\n> > ever.\n> \n> My interest in all of the proposed git-pull-training-wheel patches is\n> that they give users a way to set a finger-breaking configuration that\n> makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who\n> compulsively run 'git pull' (e.g. because SVN habits die slowly) can\n> set an option that gives them something to think about before going\n> ahead and running the pull anyway. The space in 'git pull' makes a\n> shell-side:\n> \n> $ alias 'git pull'='echo \"try fetch/merge!\"'\n> \n> solution unfeasible, and clobbering /usr/libexec/git-core/git-pull\n> seems a bit extreme.\n\nWhat is wrong with 'git pull' doing a merge when it can be fast-forward?\n\n-- \nFelipe Contreras"},{"id":"240485","messageId":"5362d7dc7b12_12fe14dd31095@nysa.notmuch","threadId":"36513","inReplyTo":"20140501200703.GB6227@odin.tremily.us","subject":"Re: Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-01T23:25:16Z","receivedAt":"2014-05-01T23:25:16Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"W. Trevor King wrote:\n> On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote:\n> > My interest in all of the proposed git-pull-training-wheel patches is\n> > that they give users a way to set a finger-breaking configuration that\n> > makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who\n> > compulsively run 'git pull' (e.g. because SVN habits die slowly) can\n> > set an option that gives them something to think about before going\n> > ahead and running the pull anyway.\n> \n> Actually, what do we think about an -i/--interactive flag (with an\n> associated pull.interactive boolean config to setup global/per-repo\n> defaults)? Then after the fetch, you'd get one of the following:\n> \n> Merge $count commits from $repository $refspec into $current_branch?\n> Rebase $count commits from $current_branch onto $repository $refpec?\n\nNot much interactivity in those options. Maybe --prompt would make more\nsense.\n\n> Fast-forward $current_branch by $count commits to $repository $refpec?\n\nWhy would anyone say 'no' to this one?\n\nBut your wording made me realize that my proposed option 'merge-ff-only'\nis not appropriate, because in theroy the user can think about it as\n'rebase-ff-only'; in other words, a 'fast-forward' is not really a\nmerge, and not really a rebase.\n\n> and have a chance to bail out if you saw:\n> \n> Merge 1003 commits from git://example.net/main.git master into my-feature?\n> \n> because you forgot which branch you were on.\n\nYes, that might be nice. But we still need to change the defaults.\n\n-- \nFelipe Contreras"},{"id":"240486","messageId":"5362d8a4de7f_12fe14dd3104f@nysa.notmuch","threadId":"36513","inReplyTo":"5362ACD6.50505@xiplink.com","subject":"Re: Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-01T23:28:36Z","receivedAt":"2014-05-01T23:28:36Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Marc Branchaud wrote:\n> So what benefit does \"git pull\" provide?\n\nThe same that 'hg update' provies: a way for the user fetch/pull the\nlatest changes and check them out into the working directory.\n\n-- \nFelipe Contreras\n"},{"id":"240487","messageId":"5362d9eeb8b30_12fe14dd310e6@nysa.notmuch","threadId":"36513","inReplyTo":"E699B6CE8ADD46618D52F05DB8EF6F07@PhilipOakley","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-01T23:34:06Z","receivedAt":"2014-05-01T23:34:06Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Philip Oakley wrote:\n> The point that there is no easy solution to an updated default pull \n> action that is right for everybody, straight out of the box, I think is \n> now fairly obvious, a summarised by Marc. I certainly avoid pull.\n\nYes, I avoid it too, and quite a lot of people.\n\n> My 'solution', if it could be called that, would be that at the point of \n> switch over, after a period of release note warning and then code \n> warning, that the plain 'git pull' would not even do the no-ff, but \n> would simply refuse to do anything...\n\nI still haven't heard a single argument why a fast-forward by default\nwouldn't be desirable.\n\nRemember that we are talking about inexperienced users here. Experienced\nusers can simply do `git pull --no-ff` or do the right configuration.\n\nThe problem we want to track is newcomers doing merges (real ones) by\nmistake.\n\nNobody ever complained about somebody doing a fast-forward by mistake.\n\nI think a non-fast-forward warning by default, and eventually rejecting\nthem is the most sensible approach.\n\n-- \nFelipe Contreras\n"},{"id":"240489","messageId":"5362db1554fa8_79d876f2f0bc@nysa.notmuch","threadId":"36513","inReplyTo":"20140501234522.GD75770@vauxhall.crustytoothpaste.net","subject":"Re: Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-01T23:39:01Z","receivedAt":"2014-05-01T23:39:01Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"brian m. carlson wrote:\n> I just used this to illustrate the fact that there isn't actually one\n> completely correct case with pull.\n\nNobody is arguing otherwise. The argument is that `git pull` by default\ncan be made more sensible.\n\n-- \nFelipe Contreras\n"},{"id":"240488","messageId":"20140501234522.GD75770@vauxhall.crustytoothpaste.net","threadId":"36513","inReplyTo":"53628CB1.8010302@xiplink.com","subject":"Re: Re: Pull is Evil","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2014-05-01T23:45:22Z","receivedAt":"2014-05-01T23:45:22Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Thu, May 01, 2014 at 02:04:33PM -0400, Marc Branchaud wrote:\n> On 14-05-01 01:56 PM, W. Trevor King wrote:\n> > On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:\n> >> On 14-05-01 05:46 AM, brian m. carlson wrote:\n> >>> git checkout maintenance-branch\n> >>> # Update our maintenance branch to the latest from the main repo.\n> >>> git pull --ff-only\n> >>> git pull --no-ff developer-remote topic-branch\n> >>> git push main-repo HEAD\n> >>\n> >> …\n> >> What's more, it seems to me that the only real advantage \"git pull\" provides\n> >> here is a less typing compared to the non-pull 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> > You're missing Brian's fast-forward merge here. It should be:\n> > \n> > git checkout maintenance-branch\n> > git fetch main-repo\n> > git merge --ff-only main-repo/maintenance-branch\n> > git fetch developer-remote\n> > …\n> \n> I think you're mistaken -- I checked out \"main-repo/maintenance-branch\"\n> directly, so there's no need to fast-forward a local branch.\n\nI actually need my local copy to be up-to-date. Part of my workflow,\nwhich I omitted for the sake of brevity, is running scripts that rely on\nmy local branch's name, format, and contents.\n\nMy use case is that I'm one of several code reviewers, and I update my\nbranch, merge in another developer's changes, review them, and then push\nthem if they're good. I need to pull from the main repo immediately\nbefore merging, to minimize the chances that someone else will have\npushed before me, which would result in me having to redo the merge\n(because the push has to be fast-forward).\n\nI just used this to illustrate the fact that there isn't actually one\ncompletely correct case with pull. I have aliases for pull (and merge)\n--ff-only and --no-ff, and I never actually use plain git pull unless I\nreally don't care whether or not it's a fast-forward. So I'm okay with\nthe status quo because I have distinct choices for merge, no merge, and\ndon't care. I don't really have a strong opinion, though, as long as\nthose three options remain.\n\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187\n"},{"id":"240490","messageId":"20140501235933.GA28634@odin.tremily.us","threadId":"36513","inReplyTo":"5362d9eeb8b30_12fe14dd310e6@nysa.notmuch","subject":"Re: Pull is Evil","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-05-01T23:59:33Z","receivedAt":"2014-05-01T23:59:33Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, May 01, 2014 at 06:34:06PM -0500, Felipe Contreras wrote:\n> Nobody ever complained about somebody doing a fast-forward by mistake.\n\nUnless they fast-forward merged a feature branch into master, but the\nproject prefers explicitly-merged feature branches with a cover-letter\nexplaination in the merge commit [1]. On the one hand, folks\nintegrating feature branches are likely more experienced Git users.\nOn the other hand, I know several project maintainers who integrate\nfeature branches that are pull-happy.\n\nI agree that accidental ff-merges are likely to be less troublesome\nthan accidental non-ff merge/rebases, but I don't think changing the\ndefault to ff-only is a perfect fix.\n\nCheers,\nTrevor\n\n[1]: http://article.gmane.org/gmane.comp.version-control.git/247807\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"240491","messageId":"20140502000208.GB28634@odin.tremily.us","threadId":"36513","inReplyTo":"5362d7dc7b12_12fe14dd31095@nysa.notmuch","subject":"Re: Re: Pull is Evil","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-05-02T00:02:08Z","receivedAt":"2014-05-02T00:02:08Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote:\n> W. Trevor King wrote:\n> > On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote:\n> > > My interest in all of the proposed git-pull-training-wheel patches is\n> > > that they give users a way to set a finger-breaking configuration that\n> > > makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who\n> > > compulsively run 'git pull' (e.g. because SVN habits die slowly) can\n> > > set an option that gives them something to think about before going\n> > > ahead and running the pull anyway.\n> > \n> > Actually, what do we think about an -i/--interactive flag (with an\n> > associated pull.interactive boolean config to setup global/per-repo\n> > defaults)? Then after the fetch, you'd get one of the following:\n> > \n> > Merge $count commits from $repository $refspec into $current_branch?\n> > Rebase $count commits from $current_branch onto $repository $refpec?\n> \n> Not much interactivity in those options. Maybe --prompt would make more\n> sense.\n\nI think matching rm, mv, cp, etc. is good, but I'd be ok with\n--prompt.\n\n> > Fast-forward $current_branch by $count commits to $repository $refpec?\n> \n> Why would anyone say 'no' to this one?\n\nBecause the want explicit merges when they bring in topic branches?\n\n> > and have a chance to bail out if you saw:\n> > \n> > Merge 1003 commits from git://example.net/main.git master into my-feature?\n> > \n> > because you forgot which branch you were on.\n> \n> Yes, that might be nice. But we still need to change the defaults.\n\nSo I should submit an orthogonal patch with -i/--interative/--prompt?\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"240502","messageId":"5362e76d5169_429131b31093@nysa.notmuch","threadId":"36513","inReplyTo":"20140501235933.GA28634@odin.tremily.us","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-02T00:31:41Z","receivedAt":"2014-05-02T00:31:41Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"W. Trevor King wrote:\n> On Thu, May 01, 2014 at 06:34:06PM -0500, Felipe Contreras wrote:\n> > Nobody ever complained about somebody doing a fast-forward by mistake.\n> \n> Unless they fast-forward merged a feature branch into master, but the\n> project prefers explicitly-merged feature branches with a cover-letter\n> explaination in the merge commit [1]. On the one hand, folks\n> integrating feature branches are likely more experienced Git users.\n\nExactly. That's barely an issue.\n\n> I agree that accidental ff-merges are likely to be less troublesome\n> than accidental non-ff merge/rebases, but I don't think changing the\n> default to ff-only is a perfect fix.\n\nI don't see what else we could do.\n\n-- \nFelipe Contreras\n"},{"id":"240503","messageId":"5362e8b09aba1_429131b31038@nysa.notmuch","threadId":"36513","inReplyTo":"20140502000208.GB28634@odin.tremily.us","subject":"Re: Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-02T00:37:04Z","receivedAt":"2014-05-02T00:37:04Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"W. Trevor King wrote:\n> On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote:\n> > W. Trevor King wrote:\n> > > On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote:\n> > > > My interest in all of the proposed git-pull-training-wheel patches is\n> > > > that they give users a way to set a finger-breaking configuration that\n> > > > makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who\n> > > > compulsively run 'git pull' (e.g. because SVN habits die slowly) can\n> > > > set an option that gives them something to think about before going\n> > > > ahead and running the pull anyway.\n> > > \n> > > Actually, what do we think about an -i/--interactive flag (with an\n> > > associated pull.interactive boolean config to setup global/per-repo\n> > > defaults)? Then after the fetch, you'd get one of the following:\n> > > \n> > > Merge $count commits from $repository $refspec into $current_branch?\n> > > Rebase $count commits from $current_branch onto $repository $refpec?\n> > \n> > Not much interactivity in those options. Maybe --prompt would make more\n> > sense.\n> \n> I think matching rm, mv, cp, etc. is good, but I'd be ok with\n> --prompt.\n\nThose are actually interactive. `git mergetool --prompt` is an exactly\nof a configration where it's interactivity is constrainted to a single\ninput.\n\n> > > Fast-forward $current_branch by $count commits to $repository $refpec?\n> > \n> > Why would anyone say 'no' to this one?\n> \n> Because the want explicit merges when they bring in topic branches?\n\nIf that was the case the user wouls have run `git merge --no-ff`. Only\nexpereinced users would answer 'no'.\n\n> > > and have a chance to bail out if you saw:\n> > > \n> > > Merge 1003 commits from git://example.net/main.git master into my-feature?\n> > > \n> > > because you forgot which branch you were on.\n> > \n> > Yes, that might be nice. But we still need to change the defaults.\n> \n> So I should submit an orthogonal patch with -i/--interative/--prompt?\n\nI'm not entirely sure what would be the ideal behavior.\n\nFor example, I'm thinking that by default when the a fast-forward is\npossible, just do it, when it's not, ask if the user wants to do a merge\nor a rebase, if the user just press 'enter' a merge is attempted.\n\nIn addition a summary of the commits ahead behind would be helpful.\n\nIf the user wants to cancel the operation, he can just do CTRL+C.\n\n-- \nFelipe Contreras"},{"id":"240508","messageId":"20140502011004.GD28634@odin.tremily.us","threadId":"36513","inReplyTo":"5362e8b09aba1_429131b31038@nysa.notmuch","subject":"Re: Pull is Evil","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-05-02T01:10:05Z","receivedAt":"2014-05-02T01:10:05Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, May 01, 2014 at 07:37:04PM -0500, Felipe Contreras wrote:\n> W. Trevor King wrote:\n> > On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote:\n> > > W. Trevor King wrote:\n> > > > Fast-forward $current_branch by $count commits to $repository\n> > > > $refpec?\n> > > \n> > > Why would anyone say 'no' to this one?\n> > \n> > Because the want explicit merges when they bring in topic\n> > branches?\n> \n> If that was the case the user wouls have run `git merge\n> --no-ff`. Only expereinced users would answer 'no'.\n\nFolks who are setting any ff options don't need any of these training\nwheels. My proposed --prompt behavior is for folks who think “I often\nrun this command without thinking it through all the way. I'm also\nnot used to reading Git's output and using 'reset --hard' with the\nreflog to reverse changes. Instead of trusting me to only say what I\nmean or leaving me to recover from mistakes, please tell me what's\nabout to change and let me opt out if I've changed my mind.”\n\n> > > > and have a chance to bail out if you saw:\n> > > > \n> > > > Merge 1003 commits from git://example.net/main.git master into my-feature?\n> > > > \n> > > > because you forgot which branch you were on.\n> > > \n> > > Yes, that might be nice. But we still need to change the defaults.\n> > \n> > So I should submit an orthogonal patch with -i/--interative/--prompt?\n> \n> I'm not entirely sure what would be the ideal behavior.\n> \n> For example, I'm thinking that by default when the a fast-forward is\n> possible, just do it, …\n\nBut just because a ff is possible doesn't mean it's what the\nuser/project wants. It may be the most likely guess, but why guess\nwhen they've explicitly asked for a prompt?\n\n> when it's not, ask if the user wants to do a merge or a rebase, if\n> the user just press 'enter' a merge is attempted.\n\nI'll just mimic however mergetool currently handles prompt\naccept/decline.\n\n> In addition a summary of the commits ahead behind would be helpful.\n\nGood idea.\n\n> If the user wants to cancel the operation, he can just do CTRL+C.\n\nI'll just mimic mergetool.\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"240510","messageId":"5362f1755f2a9_d1310572f0fa@nysa.notmuch","threadId":"36513","inReplyTo":"20140502011004.GD28634@odin.tremily.us","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-02T01:14:29Z","receivedAt":"2014-05-02T01:14:29Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"W. Trevor King wrote:\n> On Thu, May 01, 2014 at 07:37:04PM -0500, Felipe Contreras wrote:\n> > If that was the case the user wouls have run `git merge\n> > --no-ff`. Only expereinced users would answer 'no'.\n> \n> Folks who are setting any ff options don't need any of these training\n> wheels.\n\nIndeed.\n\n> My proposed --prompt behavior is for folks who think “I often run this\n> command without thinking it through all the way. I'm also not used to\n> reading Git's output and using 'reset --hard' with the reflog to\n> reverse changes. Instead of trusting me to only say what I mean or\n> leaving me to recover from mistakes, please tell me what's about to\n> change and let me opt out if I've changed my mind.”\n\nUnfortunately those folks by definition wouldn't know about the --prompt\noption.\n\n> > For example, I'm thinking that by default when the a fast-forward is\n> > possible, just do it, …\n> \n> But just because a ff is possible doesn't mean it's what the\n> user/project wants.\n\nYeah, so? We cannot read minds, especially not the minds of the people\nthat are not sitted in from of the computer.\n\n> It may be the most likely guess, but why guess when they've explicitly\n> asked for a prompt?\n\n*If* the user has specifically asked for a prompt, sure, ask. But I'm\nnot particularly interested in that, because I'm certain very very few\npeople would use --prompt.\n\nI'm interested in the defaults.\n\n-- \nFelipe Contreras"},{"id":"240517","messageId":"20140502071655.GA6288@inner.h.apk.li","threadId":"36513","inReplyTo":"5362ACD6.50505@xiplink.com","subject":"Re: Pull is Evil","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2014-05-02T07:16:55Z","receivedAt":"2014-05-02T07:16:55Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Thu, 01 May 2014 16:21:42 +0000, Marc Branchaud wrote:\n...\n> \n> But these days there's hardly any risk to using a detached HEAD. Plus\n> nowadays I think it's commonly accepted that using topic branches is a git\n> best practice. The notion of doing work on a generically-named branch like\n> \"maint\" seems archaic.\n> \n> So what benefit does \"git pull\" provide?\n\nIt provides the moral equivalent of 'cvs update', 'svn update', and\n'clearcase '.\n\nEven when I'm on a feature branch, there are cases where I have that branch\nas the current one in multiple repos (on different machines because testing),\nor multiple people working on that branch. A 'git pull' is the obvious way\nto get divergent branches back together.\n\nIn cvs&svn a local workspace can't ever be more than half a commit ahead,\nand what an 'update' does is most similar to a rebase in git. But I'm\nnot eager to teach this future userbase rebases, and also a rebase loses\nexpensive test results that are tied to the commit ids.\n\nMy personal beef with 'git pull' is still that sometimes (namely in the\n'git pull && git push' sequence) it should reverse the order of the\nparents in the merge commit, so that *my* commits look like an\nintegrated topic branch, instead of the former mainline.\n\nUnfortunately the answers to the question \"what to do instead of 'git\npull'\" are, in increasing order of teaching needed:\n\n- Ok, just 'git pull' .\n\n- Please do a 'git pull --rebase'; I'll show you how.\n\n- \n\n(I'm coming from a 'blessed repo where everybody pushes to' setup,\nand we're considering a server trigger that refuses pushes where\nthe previous head is not a *first* parent of the new head, in order\nnot to accidentally mess up the mainline.)\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"240518","messageId":"20140502074027.GB6288@inner.h.apk.li","threadId":"36513","inReplyTo":"xmqqa9b2egcy.fsf@gitster.dls.corp.google.com","subject":"Re: Pull is Evil","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2014-05-02T07:40:27Z","receivedAt":"2014-05-02T07:40:27Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Wed, 30 Apr 2014 13:01:49 +0000, Junio C Hamano wrote:\n...\n> I didn't mean \"replace 'pull' with 'update' everywhere\". I meant\n> \"Introduce 'update' that lets integrate your history into that from\n> the remote, which is to integrate in a direction opposite from how\n> 'pull' does\". \n\nThat still doesn't quite solve my problem. If I'm tracking origin/master\nin a local master branch, I can just use 'git pull' to get my 'feature'\nbranch (which is named master) updated to the current state of the origin.\nThis amounts to 'integrating' origin/master into my master.\n\nWhen I finally want to deliver and push to origin/master, I put on the\nintegrator's hat, and I cat do a 'git update' that will do the merge\nin reverse, and push the result to origin/master. The result will look\nlike origin pulled my master branch into his.\n\nProblem is that whether to use pull or update depends on whether I\nintend to push afterwards; and additionally, if I can push fast-forward\nwithout needing to 'git update' the integration into origin/master will\nlook weird.\n\n(Oh, and please don't name it 'update' - we have an important alias\nof that name.)\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"240521","messageId":"536353dfa270b_609874930cae@nysa.notmuch","threadId":"36513","inReplyTo":"20140502071655.GA6288@inner.h.apk.li","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-02T08:14:23Z","receivedAt":"2014-05-02T08:14:23Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Andreas Krey wrote:\n> My personal beef with 'git pull' is still that sometimes (namely in\n> the 'git pull && git push' sequence) it should reverse the order of\n> the parents in the merge commit, so that *my* commits look like an\n> integrated topic branch, instead of the former mainline.\n\nI haven't really thought much about this but it does make sense. How\nabout changing the behavior so `git pull` by default changes the order\nof the parents, but `git pull repo branch` doesn't.\n\n-- \nFelipe Contreras\n"},{"id":"240522","messageId":"87wqe4y3e6.fsf@fencepost.gnu.org","threadId":"36513","inReplyTo":"20140502074027.GB6288@inner.h.apk.li","subject":"Re: Pull is Evil","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-02T08:46:09Z","receivedAt":"2014-05-02T08:46:09Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Andreas Krey writes:\n\n> On Wed, 30 Apr 2014 13:01:49 +0000, Junio C Hamano wrote:\n> ...\n>> I didn't mean \"replace 'pull' with 'update' everywhere\". I meant\n>> \"Introduce 'update' that lets integrate your history into that from\n>> the remote, which is to integrate in a direction opposite from how\n>> 'pull' does\". \n>\n> That still doesn't quite solve my problem. If I'm tracking origin/master\n> in a local master branch, I can just use 'git pull' to get my 'feature'\n> branch (which is named master) updated to the current state of the origin.\n> This amounts to 'integrating' origin/master into my master.\n\nThis discussion makes as much sense to me as debating whether \"git\nfiddle\" should, in case a simple \"git hammer\" does not apply, should\ntranslate to an implied \"git screwdriver\", and when it does, whether\nmore people's workflows involve turning a screw left rather than right\nby default.\n\nWhat the gibbins? I don't even use git pull. I use git fetch, and\nthen, depending on my needs, I rebase or merge. git pull is not part of\nmy workflow exactly because it does non-connected things not translating\nunambiguously to a particular identifiable workflow. It might\nsometimes, more by accident than design, do what I would have done\nanyway. But I prefer making that choice on my own, depending on the\nparticular circumstances.\n\n-- \nDavid Kastrup\n"},{"id":"240528","messageId":"20140502145433.GF28634@odin.tremily.us","threadId":"36513","inReplyTo":"5362f1755f2a9_d1310572f0fa@nysa.notmuch","subject":"Re: Pull is Evil","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-05-02T14:54:33Z","receivedAt":"2014-05-02T14:54:33Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:\n> W. Trevor King wrote:\n> > My proposed --prompt behavior is for folks who think “I often run\n> > this command without thinking it through all the way. I'm also\n> > not used to reading Git's output and using 'reset --hard' with the\n> > reflog to reverse changes. Instead of trusting me to only say\n> > what I mean or leaving me to recover from mistakes, please tell me\n> > what's about to change and let me opt out if I've changed my\n> > mind.”\n> \n> Unfortunately those folks by definition wouldn't know about the\n> --prompt option.\n\nBut once such folks are identified, you just have to convince them\n(once) to set the pull.prompt config. That's a lot easier than\nconvincing them (for every pull) to set the appropriate ff flag.\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"240543","messageId":"5363ea28d3c14_70ef0f30c94@nysa.notmuch","threadId":"36513","inReplyTo":"20140502145433.GF28634@odin.tremily.us","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-02T18:55:36Z","receivedAt":"2014-05-02T18:55:36Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"W. Trevor King wrote:\n> On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:\n> > W. Trevor King wrote:\n> > > My proposed --prompt behavior is for folks who think “I often run\n> > > this command without thinking it through all the way. I'm also\n> > > not used to reading Git's output and using 'reset --hard' with the\n> > > reflog to reverse changes. Instead of trusting me to only say\n> > > what I mean or leaving me to recover from mistakes, please tell me\n> > > what's about to change and let me opt out if I've changed my\n> > > mind.”\n> > \n> > Unfortunately those folks by definition wouldn't know about the\n> > --prompt option.\n> \n> But once such folks are identified, you just have to convince them\n> (once) to set the pull.prompt config. That's a lot easier than\n> convincing them (for every pull) to set the appropriate ff flag.\n\nIt wouldn't matter if by the default non-fast-forward merges are\nrejected.\n\n-- \nFelipe Contreras"},{"id":"240544","messageId":"20140502190746.GJ28634@odin.tremily.us","threadId":"36513","inReplyTo":"5363ea28d3c14_70ef0f30c94@nysa.notmuch","subject":"Re: Pull is Evil","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-05-02T19:07:46Z","receivedAt":"2014-05-02T19:07:46Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:\n> W. Trevor King wrote:\n> > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:\n> > > W. Trevor King wrote:\n> > > > My proposed --prompt behavior is for folks who think “I often run\n> > > > this command without thinking it through all the way. I'm also\n> > > > not used to reading Git's output and using 'reset --hard' with the\n> > > > reflog to reverse changes. Instead of trusting me to only say\n> > > > what I mean or leaving me to recover from mistakes, please tell me\n> > > > what's about to change and let me opt out if I've changed my\n> > > > mind.”\n> > > \n> > > Unfortunately those folks by definition wouldn't know about the\n> > > --prompt option.\n> > \n> > But once such folks are identified, you just have to convince them\n> > (once) to set the pull.prompt config. That's a lot easier than\n> > convincing them (for every pull) to set the appropriate ff flag.\n> \n> It wouldn't matter if by the default non-fast-forward merges are\n> rejected.\n\nIt would matter if you didn't want them making non-fast-forward merges\n(e.g. for explicitly-merged topic branches).\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"240545","messageId":"87a9b0xahk.fsf@fencepost.gnu.org","threadId":"36513","inReplyTo":"20140502190746.GJ28634@odin.tremily.us","subject":"Re: Pull is Evil","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-02T19:10:31Z","receivedAt":"2014-05-02T19:10:31Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"W. Trevor King\" writes:\n\n> On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:\n>> W. Trevor King wrote:\n>> > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:\n>> > > W. Trevor King wrote:\n>> > > > My proposed --prompt behavior is for folks who think “I often run\n>> > > > this command without thinking it through all the way. I'm also\n>> > > > not used to reading Git's output and using 'reset --hard' with the\n>> > > > reflog to reverse changes. Instead of trusting me to only say\n>> > > > what I mean or leaving me to recover from mistakes, please tell me\n>> > > > what's about to change and let me opt out if I've changed my\n>> > > > mind.”\n>> > > \n>> > > Unfortunately those folks by definition wouldn't know about the\n>> > > --prompt option.\n>> > \n>> > But once such folks are identified, you just have to convince them\n>> > (once) to set the pull.prompt config. That's a lot easier than\n>> > convincing them (for every pull) to set the appropriate ff flag.\n>> \n>> It wouldn't matter if by the default non-fast-forward merges are\n>> rejected.\n>\n> It would matter if you didn't want them making non-fast-forward merges\n> (e.g. for explicitly-merged topic branches).\n\ns/didn't want/only wanted/\n\n-- \nDavid Kastrup\n"},{"id":"240548","messageId":"5363ee55ac2af_70ef0f30cf3@nysa.notmuch","threadId":"36513","inReplyTo":"20140502190746.GJ28634@odin.tremily.us","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-02T19:13:25Z","receivedAt":"2014-05-02T19:13:25Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"W. Trevor King wrote:\n> On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:\n> > W. Trevor King wrote:\n> > > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:\n> > > > W. Trevor King wrote:\n> > > > > My proposed --prompt behavior is for folks who think “I often run\n> > > > > this command without thinking it through all the way. I'm also\n> > > > > not used to reading Git's output and using 'reset --hard' with the\n> > > > > reflog to reverse changes. Instead of trusting me to only say\n> > > > > what I mean or leaving me to recover from mistakes, please tell me\n> > > > > what's about to change and let me opt out if I've changed my\n> > > > > mind.”\n> > > > \n> > > > Unfortunately those folks by definition wouldn't know about the\n> > > > --prompt option.\n> > > \n> > > But once such folks are identified, you just have to convince them\n> > > (once) to set the pull.prompt config. That's a lot easier than\n> > > convincing them (for every pull) to set the appropriate ff flag.\n> > \n> > It wouldn't matter if by the default non-fast-forward merges are\n> > rejected.\n> \n> It would matter if you didn't want them making non-fast-forward merges\n> (e.g. for explicitly-merged topic branches).\n\nIt would matter almost exactly zero. And just as they can do pull.promot\n= true, they can do pull.mode = fetch-only.\n\n-- \nFelipe Contreras"},{"id":"240549","messageId":"xmqqbnvgasib.fsf@gitster.dls.corp.google.com","threadId":"36513","inReplyTo":"5362ACD6.50505@xiplink.com","subject":"Re: Pull is Evil","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-02T19:29:48Z","receivedAt":"2014-05-02T19:29:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Branchaud writes:\n\n> I may be mistaken, but I think \"git pull\" evolved to try to address the\n> detached-HEAD risk (at least in part).\n\nYou are totally mistaken.\n\n\"git pull\" was part of the things to make git usable by Linus before\n1.0 release, and matches the integrator workflow perfectly well.\nThe detached HEAD came much much later.\n\nThe issue we are discussing with \"git pull\" is that if a non\nintegrator does a \"git pull\" from the upstream, in order to push the\nresult of integrating the local work with it back to the upstream,\nby default \"git pull\" creates a merge in a direction that is wrong\nwhen seen in the \"first-parent chain is the trunk\" point of view.\n\nOne way to solve that _might_ be to use the detached HEAD as you\nillustrated in your long-hand in the thread that had Brian's\nexample, but that is not even a failed 'git push' recommends to do\nto the users, and there was no link between how 'git pull' behaves\nand use of detached HEAD at all.\n"},{"id":"240554","messageId":"20140502194637.GL28634@odin.tremily.us","threadId":"36513","inReplyTo":"5363ee55ac2af_70ef0f30cf3@nysa.notmuch","subject":"Re: Pull is Evil","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-05-02T19:46:37Z","receivedAt":"2014-05-02T19:46:37Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:\n> W. Trevor King wrote [1]:\n> > On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:\n> > > W. Trevor King wrote:\n> > > > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:\n> > > > > W. Trevor King wrote:\n> > > > > > My proposed --prompt behavior is for folks who think “I often run\n> > > > > > this command without thinking it through all the way. I'm also\n> > > > > > not used to reading Git's output and using 'reset --hard' with the\n> > > > > > reflog to reverse changes. Instead of trusting me to only say\n> > > > > > what I mean or leaving me to recover from mistakes, please tell me\n> > > > > > what's about to change and let me opt out if I've changed my\n> > > > > > mind.”\n> > > > > \n> > > > > Unfortunately those folks by definition wouldn't know about the\n> > > > > --prompt option.\n> > > > \n> > > > But once such folks are identified, you just have to convince them\n> > > > (once) to set the pull.prompt config. That's a lot easier than\n> > > > convincing them (for every pull) to set the appropriate ff flag.\n> > > \n> > > It wouldn't matter if by the default non-fast-forward merges are\n> > > rejected.\n> > \n> > It would matter if you [only wanted] them making non-fast-forward\n> > merges (e.g. for explicitly-merged topic branches).\n> \n> It would matter almost exactly zero.\n\nSome folks have explicit merge policies, and deciding how much that\nmatters is probably best left up to the projects themselves and not\ndecided in Git code. I like having a place to explain why a feature\nis useful and has been included in projects I maintain.\n\n> And just as they can do pull.promot = true, they can do pull.mode =\n> fetch-only.\n\nWhy would you run a fetch-only pull instead of running 'git fetch'? I\nthink it would make more sense to have 'pull.mode = none' with which\n'git pull …' turns into a no-op suggesting an explicit\nfetch/{merge|rebase}. Having something like that available would\nhelp with the training issue that pull.prompt was addressing.\n\nCheers,\nTrevor\n\n[1]: With David Kastrup's \"only wanted\" typo fix.\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"240555","messageId":"xmqqy4yk9cty.fsf@gitster.dls.corp.google.com","threadId":"36513","inReplyTo":"xmqqbnvgasib.fsf@gitster.dls.corp.google.com","subject":"Re: Pull is Evil","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-02T19:53:45Z","receivedAt":"2014-05-02T19:53:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Marc Branchaud writes:\n>\n>> I may be mistaken, but I think \"git pull\" evolved to try to address the\n>> detached-HEAD risk (at least in part).\n>\n> You are totally mistaken.\n>\n> \"git pull\" was part of the things to make git usable by Linus before\n> 1.0 release, and matches the integrator workflow perfectly well.\n> The detached HEAD came much much later.\n>\n> The issue we are discussing with \"git pull\" is that if a non\n> integrator does a \"git pull\" from the upstream, in order to push the\n> result of integrating the local work with it back to the upstream,\n> by default \"git pull\" creates a merge in a direction that is wrong\n> when seen in the \"first-parent chain is the trunk\" point of view.\n>\n> One way to solve that _might_ be to use the detached HEAD as you\n> illustrated in your long-hand in the thread that had Brian's\n> example, but that is not even a failed 'git push' recommends to do\n> to the users, and there was no link between how 'git pull' behaves\n> and use of detached HEAD at all.\n\nOne other thing to keep in mind is that the \"first-parent\" view\nitself is fairly new, compared to \"git pull\" (and it is even newer\nthan detached HEAD IIRC, but I do not think detached HEAD has much\nto do with the current \"'git pull' is often harmful\" confusion,\nexcept that it may be one ingredient for a possible solution).\n\nBack when we started \"A simple CVS/SVN like workflow can be done by\ncycles of 'git pull', do your work, 'git push'\", the order of\nparents in resulting merges was not an issue.\n\nI am only saying these to give people the historical background to\ndiscuss a possible solution. I am not saying that it is a possible\nsolution to discourage the \"first-parent chain is the mainline of\nthe development\" world view.\n"},{"id":"240562","messageId":"5364015a94900_135215292ec28@nysa.notmuch","threadId":"36513","inReplyTo":"20140502194637.GL28634@odin.tremily.us","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-02T20:34:34Z","receivedAt":"2014-05-02T20:34:34Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"W. Trevor King wrote:\n> On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:\n> > It would matter almost exactly zero.\n> \n> Some folks have explicit merge policies, and deciding how much that\n> matters is probably best left up to the projects themselves and not\n> decided in Git code.\n\nLet's make some fake numbers to see around how much this would matter.\nThe amount of people that are not used to Git could be around 60%.\n\nOf these, the amount that would be doing integration is probably 30%, as\nthose tasks would be relegated to more advanced users. A project that\nlets non-advanced users to integration probably wouldn't care if the\nmerges are fast-forward or not, but let's say 10% of them do. That makes\n3%.\n\nOn the other hand, user might do merges when trying to bring their local\nrepositories up-to-date, let's say 100% of them do. Of those, the ones\nin a project that doesn't want fast-forward merges is probably 10%. That\nmakes 10%. However, such projects wouldn't want them merging\n'origin/master' to 'master', but 'topic' to 'master', so they shouldn't\nbe using `git pull` anyway, but for the sake of argument let's say that\nthey do.\n\nThat would make around 8%, and 6% of those wouldn't be using `git pull`\nanyway.\n\nSo no, for all intents and purposes it doesn't matter. I would rather\nconcentrate on the issue more than 90% of the users face.\n\n> > And just as they can do pull.promot = true, they can do pull.mode =\n> > fetch-only.\n> \n> Why would you run a fetch-only pull instead of running 'git fetch'? I\n> think it would make more sense to have 'pull.mode = none' with which\n> 'git pull …' turns into a no-op suggesting an explicit\n> fetch/{merge|rebase}. Having something like that available would\n> help with the training issue that pull.prompt was addressing.\n\nI fail to see how training them to do this:\n\n % git config --global pull.mode none\n % git pull\n % git fetch\n % git merge --no-ff\n\nIs preferable than training them to do:\n\n % git pull --no-ff\n\n-- \nFelipe Contreras"},{"id":"240569","messageId":"20140502205648.GA5188@wheezy.local","threadId":"36513","inReplyTo":"4ay6w9i74cygt6ii1b0db7wg.1398433713382@email.android.com","subject":"Re: A failing attempt to use Git in a centralized environment","fromName":"Max Kirillov","fromEmail":"max@max630.net","sentAt":"2014-05-02T20:56:48Z","receivedAt":"2014-05-02T20:56:48Z","isPatch":false,"sender":{"key":"max@max630.net","avatar":"https://avatars.githubusercontent.com/u/381560?v=4"},"body":"Hi.\n\n> Problem #6: push - reject - pull - push sequence sometimes transforms\n> into a loop with several iterations and doesn't add happiness.\n\nAs far as I undestand, this is the most annoying thing. In\ngit (like other distributed systems), you cannot push your\nchanges unless you merge them with a very last version of\nthe whole repository.\n\nI think the only good way to use git in a team with more\nthan a very few persons is to switch to pull-request based\nworkflow, which does not require users to update to push\ntheir changes. Then their changes are merged to master\neither by a human integrator or by a tool (gitorious,\ngithub, stash, gerrit etc.).\n\nI think it can be even as little as 'update' hook, thich is\ntriggered when user pushes to branch like 'inbox/bob' and\ntries to merge the branch to master. The only issue I can\nsee with it is that does not provide a way to specify\nmeaningful merge message.\n\nBtw, then the problem#2 is not a problem, because the merge\ndone by user does not yet produce the commit to be added to\nmaster, but just prepares more recent version - to resolves\nconflicts or check how the changes work against newer\ncodebase. One more merge is still performed by the server,\nand parent order is correct:\n\nmaster =====+===+======2\n \\ \\ /\nyour copy +===1==+\n\n-- \nMax\n"},{"id":"240574","messageId":"20140502211305.GN28634@odin.tremily.us","threadId":"36513","inReplyTo":"5364015a94900_135215292ec28@nysa.notmuch","subject":"Re: Pull is Evil","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-05-02T21:13:05Z","receivedAt":"2014-05-02T21:13:05Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:\n> W. Trevor King wrote:\n> > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:\n> > > It would matter almost exactly zero.\n> > \n> > Some folks have explicit merge policies, and deciding how much\n> > that matters is probably best left up to the projects themselves\n> > and not decided in Git code.\n> \n> Let's make some fake numbers to see around how much this would matter.\n\nThe point isn't that this is a huge flaw, the point is that we should\nbe able to configure Git to match sane workflows. Saying “that's\nunlikely to happen” doesn't solve the problem that some newcomers have\ntrouble matching their project's desired workflow.\n\n> So no, for all intents and purposes it doesn't matter. I would rather\n> concentrate on the issue more than 90% of the users face.\n\nYou don't have to concentrate on it, because I'm willing to write up\nthe patch, I'm just trying to find a consensus spec before writing the\npatch. If you don't have strong feelings about a pull.prompt\nproposal, I won't mind ;). I just don't want to write it up and\n*then* hear “that's a terrible idea, you should have just done $x.”.\n\n> > > And just as they can do pull.promot = true, they can do pull.mode =\n> > > fetch-only.\n> > \n> > Why would you run a fetch-only pull instead of running 'git fetch'? I\n> > think it would make more sense to have 'pull.mode = none' with which\n> > 'git pull …' turns into a no-op suggesting an explicit\n> > fetch/{merge|rebase}. Having something like that available would\n> > help with the training issue that pull.prompt was addressing.\n> \n> I fail to see how training them to do this:\n> \n> % git config --global pull.mode none\n> % git pull\n> % git fetch\n> % git merge --no-ff\n> \n> Is preferable than training them to do:\n> \n> % git pull --no-ff\n\nThe goal is to train them to do:\n\n> % git config --global pull.mode none\n> % git fetch\n> % git merge --no-ff\n\nThe 'git pull' (with 'none' mode) explainer just helps retrain folks\nthat are already using the current 'git pull' incorrectly.\n\nThe benefit is that the repeated pair of commands (fetch/merge) takes\nlonger to type, which gives them longer to realize that they should\nthink about what they're doing and abort. That's all a pull.prompt\nwould be doing anyway.\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"240576","messageId":"53640bc1ee6eb_135215292ec95@nysa.notmuch","threadId":"36513","inReplyTo":"20140502211305.GN28634@odin.tremily.us","subject":"Re: Pull is Evil","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-02T21:18:57Z","receivedAt":"2014-05-02T21:18:57Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"W. Trevor King wrote:\n> On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:\n> > W. Trevor King wrote:\n> > > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:\n> > > > It would matter almost exactly zero.\n> > > \n> > > Some folks have explicit merge policies, and deciding how much\n> > > that matters is probably best left up to the projects themselves\n> > > and not decided in Git code.\n> > \n> > Let's make some fake numbers to see around how much this would matter.\n> \n> The point isn't that this is a huge flaw, the point is that we should\n> be able to configure Git to match sane workflows.\n\nThe point is that we are tainting a discussion about how to improve the\ndefaults for the vast majority of users, and given Git's history, the\nmost likely outcome is that nothing will happen, neither for the\nmajority, nor the tiny minority.\n\n> Saying “that's unlikely to happen” doesn't solve the problem that some\n> newcomers have trouble matching their project's desired workflow.\n\n% git config --global pull.ff false\n\nDone.\n\n> The goal is to train them to do:\n> \n> > % git config --global pull.mode none\n> > % git fetch\n> > % git merge --no-ff\n> \n> The 'git pull' (with 'none' mode) explainer just helps retrain folks\n> that are already using the current 'git pull' incorrectly.\n\nIf you are going to train them to use a configuration, it should be:\n\n% git config --global pull.ff false\n\n-- \nFelipe Contreras"},{"id":"240578","messageId":"20140502220107.GO28634@odin.tremily.us","threadId":"36513","inReplyTo":"53640bc1ee6eb_135215292ec95@nysa.notmuch","subject":"pull.prompt or other way to slow/disable 'git pull' (was: Pull is Evil)","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-05-02T22:01:07Z","receivedAt":"2014-05-02T22:01:07Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, May 02, 2014 at 04:18:57PM -0500, Felipe Contreras wrote:\n> W. Trevor King wrote:\n> > On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:\n> > > W. Trevor King wrote:\n> > > > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:\n> > > > > It would matter almost exactly zero.\n> > > > \n> > > > Some folks have explicit merge policies, and deciding how much\n> > > > that matters is probably best left up to the projects themselves\n> > > > and not decided in Git code.\n> > > \n> > > Let's make some fake numbers to see around how much this would matter.\n> > \n> > The point isn't that this is a huge flaw, the point is that we should\n> > be able to configure Git to match sane workflows.\n> \n> The point is that we are tainting a discussion about how to improve the\n> defaults for the vast majority of users\n\nI've renamed this sub-thread (which started around $gmane/247835) to\navoid potential confusion/dilution.\n\n> > The goal is to train them to do:\n> > \n> > > % git config --global pull.mode none\n> > > % git fetch\n> > > % git merge --no-ff\n\nSticking to my 'no-ff' topic branch example, this should have been:\n\n git merge --no-ff remote branch\n\nI want folks to use --ff-only when pulling their default upstream.\n\n> > The 'git pull' (with 'none' mode) explainer just helps retrain folks\n> > that are already using the current 'git pull' incorrectly.\n> \n> If you are going to train them to use a configuration, it should be:\n> \n> % git config --global pull.ff false\n\nI don't want all pulls to be --no-ff, only pulls from topic branches.\nI think adding a prompt or making the integration a two-step\nfetch/merge are both ways to jog a user into consciously evaluating\ntheir actions. I don't see how a changing the default single-step\npull strategy (whatever it is) will. I also don't look forward to\nexplaining an adaptive strategy that tries to get my workflow right\nwithout command-line ff options to folks on their first day using Git.\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"240588","messageId":"53641a1be8d24_1c7bdcd2f049@nysa.notmuch","threadId":"36513","inReplyTo":"20140502220107.GO28634@odin.tremily.us","subject":"RE: pull.prompt or other way to slow/disable 'git pull' (was: Pull is Evil)","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-02T22:20:11Z","receivedAt":"2014-05-02T22:20:11Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"W. Trevor King wrote:\n> I've renamed this sub-thread (which started around $gmane/247835) to\n> avoid potential confusion/dilution.\n\nThanks.\n\n> > > The goal is to train them to do:\n> > > \n> > > > % git config --global pull.mode none\n> > > > % git fetch\n> > > > % git merge --no-ff\n> \n> Sticking to my 'no-ff' topic branch example, this should have been:\n> \n> git merge --no-ff remote branch\n> \n> I want folks to use --ff-only when pulling their default upstream.\n\nThat's proposed to be the default anyway, so they won't need it.\n\n> > > The 'git pull' (with 'none' mode) explainer just helps retrain folks\n> > > that are already using the current 'git pull' incorrectly.\n> > \n> > If you are going to train them to use a configuration, it should be:\n> > \n> > % git config --global pull.ff false\n> \n> I don't want all pulls to be --no-ff, only pulls from topic branches.\n\nPulling some branch to a topic branch, or pulling a topic branch to\nanother branch?\n\nEither way, since I think these two are different modes:\n\n 1) git pull\n 2) git pull origin topic\n\nMaybe it would actually make sense to have a configuration specific to\n2): pull.topicmode.\n\nThis way they could do \"pull.topicmode = merge-no-ff\". Or maybe we need\narguments: \"pull.topicargs = --merge --no-ff\".\n\n-- \nFelipe Contreras\n"},{"id":"240601","messageId":"20140503000530.GP28634@odin.tremily.us","threadId":"36513","inReplyTo":"53641a1be8d24_1c7bdcd2f049@nysa.notmuch","subject":"Re: pull.prompt or other way to slow/disable 'git pull'","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-05-03T00:05:30Z","receivedAt":"2014-05-03T00:05:30Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote:\n> W. Trevor King wrote:\n> > > > The 'git pull' (with 'none' mode) explainer just helps retrain folks\n> > > > that are already using the current 'git pull' incorrectly.\n> > > \n> > > If you are going to train them to use a configuration, it should be:\n> > > \n> > > % git config --global pull.ff false\n> > \n> > I don't want all pulls to be --no-ff, only pulls from topic branches.\n> \n> Pulling some branch to a topic branch, or pulling a topic branch to\n> another branch?\n\nThe latter. Here's a more detailed list:\n\n1. HEAD: an integration branch (master, maint, …)\n target: @{upstream}, branch.*.pushremote, and other mirrors\n my preferred integration mode: ff-only merge the target\n\n2. HEAD: an integration branch\n target: a *different* branch (e.g. maint or feature-x, but not\n origin/master or jdoe/master, if HEAD is master)\n my preferred integration mode: no-ff merge the target into HEAD.\n\n3. HEAD: a topic branch (e.g. feature-x)\n target: a collaborating topic branch (jdoe/feature-x)\n my preferred integration mode: ff-only merge the target\n\n4. HEAD: a topic branch (e.g. feature-x)\n target: a related topic branch (e.g. jdoe/feature-y) or integration\n branch updates used by my feature-x\n my preferred integration mode: rebase feature-x onto the target\n\nCases 1 and 2 can usually be distinguished by comparing the\nchecked-out branch with the branch portion of the remote-tracking\nreference), but for folks developing in master, jdoe/master may be a\nfeature branch (case 2) not a mirror of the maintenance branch (case\n1).\n\nCases 1 and 3 are the same idea, with any feature branch running long\nenough to get collaborators being indistinguishable from an\nintegration branch except that the latter will eventually be merged\n(or dropped) and deleted.\n\nIn the event of non-trivial merge conflicts in case 2, I sometimes\nrebase the target onto HEAD and no-ff merge the resulting target'. On\nthe other hand, sometimes rebasing is not an option. For example, if\nI want to merge the target into both master and maint, but master\ncontains a conflicting commit A:\n\n -o---o---A---o---B master\n |\\\n | o---o---C maint\n \\\n o---D target\n\nRebasing would drag A into maint at F:\n\n -o---o---A---o---B---E master\n \\ \\ /\n \\ o---D'--- target'\n \\ \\\n o---o---C---F maint\n\nAnd I don't want both the pre- and post-rebase versions in my history\nat G:\n\n -o---o---A---o---B---E---G master\n |\\ \\ / /\n | \\ o---D'--- / target'\n | \\ /\n | o---o---C---F---- maint\n \\ /\n o---D-------- target\n\nSo I'd just deal with a complicated merge at E:\n\n -o---o---A---o---B---E---G master\n |\\ / /\n | o---D------------ / target\n \\ \\ /\n o---o---C---F------ maint\n\nCase 4 has similar caveats, since you don't want to rebase feature-x\non top of jdoe/feature-y if there are already other branches based on\nthe current feature-x that can't (or won't) be rebased.\n\n> Either way, since I think these two are different modes:\n> \n> 1) git pull\n> 2) git pull origin topic\n> \n> Maybe it would actually make sense to have a configuration specific to\n> 2): pull.topicmode.\n\nI think it makes more sense to just use merge/rebase explicitly, and\nnot try and bundle all of this complication into something that *also*\nfetches. Unfortunately, there's currently no finger-breaker to help\ncompulsive pull users break the habit or keep novices from starting.\nAdding more elaborate handling to pull just pushes back the point\nwhere you reach something that is pretty much impossible to resolve\nautomatically (like my case 2 caveat). When that happens, it would be\nnice to have a workflow independent way to calm the pull-happy user\n(e.g. pull.mode=none, or pull.prompt=true) while they learn to\nexplicitly use fetch/{merge|rebase} or more careful pulls.\n\nCheers,\nTrevor\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"240609","messageId":"20140503061717.GA19561@inner.h.apk.li","threadId":"36513","inReplyTo":"87wqe4y3e6.fsf@fencepost.gnu.org","subject":"Re: Pull is Evil","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2014-05-03T06:17:17Z","receivedAt":"2014-05-03T06:17:17Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Fri, 02 May 2014 10:46:09 +0000, David Kastrup wrote:\n...\n> What the gibbins? I don't even use git pull.\n\nI do, but I watch for the fast-forward message\nand undo as appropriate.\n\n> I use git fetch, and then, depending on my needs, I rebase or merge.\n\nI wouldn't mind that, but I have a century of newbies who are used\nto having other people's changes appear in their workspace without\nany interaction. Teaching them the mainline thing (aka first-parent)\nand the commands to properly merge&push is...tricky.\n\nAnd that goes for every user base, so some improvement would be\ngreatly appreciated.\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"240611","messageId":"87siorwdum.fsf@fencepost.gnu.org","threadId":"36513","inReplyTo":"20140503061717.GA19561@inner.h.apk.li","subject":"Re: Pull is Evil","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-03T06:55:29Z","receivedAt":"2014-05-03T06:55:29Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Andreas Krey writes:\n\n> On Fri, 02 May 2014 10:46:09 +0000, David Kastrup wrote:\n> ...\n>> What the gibbins? I don't even use git pull.\n>\n> I do, but I watch for the fast-forward message\n> and undo as appropriate.\n>\n>> I use git fetch, and then, depending on my needs, I rebase or merge.\n>\n> I wouldn't mind that, but I have a century of newbies who are used\n> to having other people's changes appear in their workspace without\n> any interaction. Teaching them the mainline thing (aka first-parent)\n> and the commands to properly merge&push is...tricky.\n>\n> And that goes for every user base, so some improvement would be\n> greatly appreciated.\n\nI've seen the proposals for \"git update\" and whatever. It's sort of\nlike having an assembly line where there are separate automatic screw\ndrivers for screwing and unscrewing. The latter are hard to find in the\nrare case you need them, with quite different handling and looks.\n\nThis is modeled after the successful fastening model for nails, where\nhammer and pliers look and behave quite differently, so people are used\nto handle and arrange hammer and pliers on different racks and have\ndifferent numbers for them.\n\nSince this model works well for nails, let's employ it for screws as\nwell and call right-turning screwdrivers \"hammers\" and left-turning\nscrewdrivers \"pliers\" and sort them accordingly in order to avoid\nconfusion for beginners and help them learn to deal with screws properly\nand deftly.\n\n-- \nDavid Kastrup\n"},{"id":"240623","messageId":"5364bbfc8c0a0_ac68dd308ce@nysa.notmuch","threadId":"36513","inReplyTo":"20140503000530.GP28634@odin.tremily.us","subject":"Re: pull.prompt or other way to slow/disable 'git pull'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-03T09:50:52Z","receivedAt":"2014-05-03T09:50:52Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"W. Trevor King wrote:\n> On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote:\n> > W. Trevor King wrote:\n> > > > > The 'git pull' (with 'none' mode) explainer just helps retrain folks\n> > > > > that are already using the current 'git pull' incorrectly.\n> > > > \n> > > > If you are going to train them to use a configuration, it should be:\n> > > > \n> > > > % git config --global pull.ff false\n> > > \n> > > I don't want all pulls to be --no-ff, only pulls from topic branches.\n> > \n> > Pulling some branch to a topic branch, or pulling a topic branch to\n> > another branch?\n> \n> The latter. Here's a more detailed list:\n> \n> 1. HEAD: an integration branch (master, maint, …)\n> target: @{upstream}, branch.*.pushremote, and other mirrors\n> my preferred integration mode: ff-only merge the target\n\n`git pull` would do that by default.\n\n> 2. HEAD: an integration branch\n> target: a *different* branch (e.g. maint or feature-x, but not\n> origin/master or jdoe/master, if HEAD is master)\n> my preferred integration mode: no-ff merge the target into HEAD.\n\nThat makes sense, but other people would be OK with a ff merge.\n\n> 3. HEAD: a topic branch (e.g. feature-x)\n> target: a collaborating topic branch (jdoe/feature-x)\n> my preferred integration mode: ff-only merge the target\n\nI don't see why. It will alomst always be non-fast-fowrward, so you\nshould already be prepared for a merge (or rebase).\n\n> 4. HEAD: a topic branch (e.g. feature-x)\n> target: a related topic branch (e.g. jdoe/feature-y) or integration\n> branch updates used by my feature-x\n> my preferred integration mode: rebase feature-x onto the target\n\nNah. Most people would prefer a merge. And actually, quite many would\nwant jdoe/feature-y to be rebased on top of feature-x.\n\nEither way it would be impossible for Git to figre out what you want to\ndo.\n\n> Cases 1 and 2 can usually be distinguished by comparing the\n> checked-out branch with the branch portion of the remote-tracking\n> reference), but for folks developing in master, jdoe/master may be a\n> feature branch (case 2) not a mirror of the maintenance branch (case\n> 1).\n\nI'd say they can be distinguished by what the user typed.\n \n> Cases 1 and 3 are the same idea, with any feature branch running long\n> enough to get collaborators being indistinguishable from an\n> integration branch except that the latter will eventually be merged\n> (or dropped) and deleted.\n\nIneed, so why would you want so drastically different behavior?\n \n> In the event of non-trivial merge conflicts in case 2, I sometimes\n> rebase the target onto HEAD and no-ff merge the resulting target'. On\n> the other hand, sometimes rebasing is not an option. For example, if\n> I want to merge the target into both master and maint, but master\n> contains a conflicting commit A:\n> \n> -o---o---A---o---B master\n> |\\\n> | o---o---C maint\n> \\\n> o---D target\n> \n> Rebasing would drag A into maint at F:\n> \n> -o---o---A---o---B---E master\n> \\ \\ /\n> \\ o---D'--- target'\n> \\ \\\n> o---o---C---F maint\n> \n> And I don't want both the pre- and post-rebase versions in my history\n> at G:\n> \n> -o---o---A---o---B---E---G master\n> |\\ \\ / /\n> | \\ o---D'--- / target'\n> | \\ /\n> | o---o---C---F---- maint\n> \\ /\n> o---D-------- target\n> \n> So I'd just deal with a complicated merge at E:\n> \n> -o---o---A---o---B---E---G master\n> |\\ / /\n> | o---D------------ / target\n> \\ \\ /\n> o---o---C---F------ maint\n> \n> Case 4 has similar caveats, since you don't want to rebase feature-x\n> on top of jdoe/feature-y if there are already other branches based on\n> the current feature-x that can't (or won't) be rebased.\n\nWhat I do in those cases is do both a merge and a rebase. If I resolved\nthe conflicts correctly in the rebase the result of the merge should be\nexactly the same. It's not hard because rerere stores the conflict\nresolutions of the rebase and the merge becomes much simpler. After I'm\ncertain the merge is correct, I remove the temporary rebased branch.\n\nAnyway I don't see how is this possibly relevant to the topic at hand.\n\n> > Either way, since I think these two are different modes:\n> > \n> > 1) git pull\n> > 2) git pull origin topic\n> > \n> > Maybe it would actually make sense to have a configuration specific to\n> > 2): pull.topicmode.\n> \n> I think it makes more sense to just use merge/rebase explicitly,\n\nFine, if you want the user to be explicit, he can be explicit with\n`git pull --no-ff origin topic`. Problem solved.\n\n-- \nFelipe Contreras"},{"id":"240672","messageId":"CAEBDL5XZGz3uRAhnvtPmjWH0i=MLz08MkEGvJVRfj2MLunq++Q@mail.gmail.com","threadId":"36513","inReplyTo":"5BA0AC67-CDD6-4725-B75D-B98F957EB51E@mac.com","subject":"Re: A failing attempt to use Git in a centralized environment","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2014-05-04T08:58:20Z","receivedAt":"2014-05-04T08:58:20Z","isPatch":false,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Wed, Apr 30, 2014 at 1:15 PM, Geert Bosch wrote:\n>\n> On Apr 28, 2014, at 02:29, Marat Radchenko wrote:\n>\n>> In short:\n>> 1. Hack, hack, hack\n>> 2. Commit\n>> 3. Push, woops, reject (non-ff)\n>> 4. Pull\n>> 5. Push\n>\n> Just do pull --rebase? This is essentially the same as what SVN\n> used to do in your setup.\n\nThat's not necessarily a good solution either. For teams that don't\nuse rebase, it can leave them with their newly committed stuff now\nrebased on the work from upstream--duplicating commits without\nunderstanding why and where they came from, especially if other\nbranches were built on top of that one.\n\nI agree in concept, but in practice it can be quite confusing. :-(\n\n-John\n"},{"id":"240694","messageId":"20140504185145.GQ28634@odin.tremily.us","threadId":"36513","inReplyTo":"5364bbfc8c0a0_ac68dd308ce@nysa.notmuch","subject":"Re: pull.prompt or other way to slow/disable 'git pull'","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2014-05-04T18:51:45Z","receivedAt":"2014-05-04T18:51:45Z","isPatch":false,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Sat, May 03, 2014 at 04:50:52AM -0500, Felipe Contreras wrote:\n> Either way it would be impossible for Git to figre out what you want\n> to do.\n\nThat's my point. The details of my particular workflow are\nunimportant.\n\n> Anyway I don't see how is this possibly relevant to the topic at\n> hand.\n\nI'm trying to motivate a way to slow/disable 'git pull', which I see\nas orthogonal to your push to change the default configuration. I\nthought describing my workflow in more detail would help clarify why…\n\n> W. Trevor King wrote:\n> > On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote:\n> > > W. Trevor King wrote:\n> > > > > > The 'git pull' (with 'none' mode) explainer just helps retrain folks\n> > > > > > that are already using the current 'git pull' incorrectly.\n> > > > > \n> > > > > If you are going to train them to use a configuration, it should be:\n> > > > > \n> > > > > % git config --global pull.ff false\n> > > > \n> > > > I don't want all pulls to be --no-ff, only pulls from topic branches.\n\n… this global pull.ff config was not a solution.\n\n> > > Either way, since I think these two are different modes:\n> > > \n> > > 1) git pull\n> > > 2) git pull origin topic\n> > > \n> > > Maybe it would actually make sense to have a configuration specific to\n> > > 2): pull.topicmode.\n> > \n> > I think it makes more sense to just use merge/rebase explicitly,\n> \n> Fine, if you want the user to be explicit, he can be explicit with\n> `git pull --no-ff origin topic`. Problem solved.\n\nThat's certainly explicit, but some folks are in the habit of just\nrunning 'git pull' (regardless of which branch they happen to be on)\nwithout thinking “Where am I, what am I integrating, and how should I\nintegrate it?”. As I claimed earlier:\n\nOn Thu, May 01, 2014 at 06:10:04PM -0700, W. Trevor King wrote [1]:\n> Folks who are setting any ff options don't need any of these\n> training wheels. My proposed --prompt behavior is for folks who\n> think “I often run this command without thinking it through all the\n> way. I'm also not used to reading Git's output and using 'reset\n> --hard' with the reflog to reverse changes. Instead of trusting me\n> to only say what I mean or leaving me to recover from mistakes,\n> please tell me what's about to change and let me opt out if I've\n> changed my mind.”\n\nIn the messages following that, you seemed to agree that such folks\nexisted [2], and suggested I use pull.mode=fetch-only [3] or\npull.ff=false [4] or pull.topicargs='--merge --no-ff' [5]. Now we\nagree (I think? Based on your “it would be impossible for Git…”\nquoted above) that you can have a sane workflow for which no\npull-strategy default will always do the right thing. We just\ndisagree (I think) on what to do about it. I'm suggesting\npull.prompt, pull.mode=none, or some other way to slow/disable 'git\npull' while folks retrain themselves. You're suggesting (I think?\nBased on your 'git pull --no-ff origin topic' quoted above) that folks\njust skip right to remembering which ff options to use in which\nsituations. Do you feel folks won't need a way to slow/disable 'git\npull' while they build the ff options and their project's recommended\nworkflow into their own practice? Or do you agree that they will need\nsome kind of helper for the transition, and just feel that git.prompt\nis the wrong helper?\n\nCheers,\nTrevor\n\n[1]: http://article.gmane.org/gmane.comp.version-control.git/247917\n[2]: http://article.gmane.org/gmane.comp.version-control.git/247919\n On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:\n > W. Trevor King wrote:\n > > Folks who are setting any ff options don't need any of these\n > > training wheels.\n >\n > Indeed.\n[3]: http://article.gmane.org/gmane.comp.version-control.git/247957\n On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:\n > W. Trevor King wrote:\n > > On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:\n > > > W. Trevor King wrote:\n > > > > But once such folks are identified, you just have to\n > > > > convince them (once) to set the pull.prompt config.\n > > > > That's a lot easier than convincing them (for every pull)\n > > > > to set the appropriate ff flag.\n > > >\n > > > It wouldn't matter if by the default non-fast-forward\n > > > merges are rejected.\n > >\n > > It would matter if you didn't want them making\n > > non-fast-forward merges (e.g. for explicitly-merged topic\n > > branches).\n >\n > It would matter almost exactly zero. And just as they can do\n > pull.promot = true, they can do pull.mode = fetch-only.\n[4]: http://article.gmane.org/gmane.comp.version-control.git/247986\n On Fri, May 02, 2014 at 04:18:57PM -0500, Felipe Contreras wrote:\n > W. Trevor King wrote:\n > > Saying “that's unlikely to happen” doesn't solve the problem\n > > that some newcomers have trouble matching their project's\n > > desired workflow.\n >\n > % git config --global pull.ff false\n >\n > Done.\n[5]: http://article.gmane.org/gmane.comp.version-control.git/247998\n On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote:\n > W. Trevor King wrote:\n > > I don't want all pulls to be --no-ff, only pulls from topic\n > > branches.\n >\n > Pulling some branch to a topic branch, or pulling a topic\n > branch to another branch?\n >\n > Either way, since I think these two are different modes:\n >\n > 1) git pull\n > 2) git pull origin topic\n >\n > Maybe it would actually make sense to have a configuration\n > specific to 2): pull.topicmode.\n >\n > This way they could do \"pull.topicmode = merge-no-ff\". Or maybe\n > we need arguments: \"pull.topicargs = --merge --no-ff\".\n\n-- \nThis email may be signed or encrypted with GnuPG (http://www.gnupg.org).\nFor more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\n"},{"id":"240702","messageId":"5366a8f2c6095_18f9e4b30811@nysa.notmuch","threadId":"36513","inReplyTo":"20140504185145.GQ28634@odin.tremily.us","subject":"Re: pull.prompt or other way to slow/disable 'git pull'","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2014-05-04T20:54:10Z","receivedAt":"2014-05-04T20:54:10Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"W. Trevor King wrote:\n> Do you feel folks won't need a way to slow/disable 'git pull' while\n> they build the ff options and their project's recommended workflow\n> into their own practice?\n\nThat's right.\n\n> Or do you agree that they will need some kind of helper for the\n> transition, and just feel that git.prompt is the wrong helper?\n\nI feel helpers are good when we are transitioning from an established\nGit behavior to a new one. Or when the operation is potentially\ndangerous.\n\nBut a fast-forward merge is not dangerous, an in fact it's what the vast\nmajority of people would want.\n\nEven more, I'm now feeling confident I will be able to put a proposal\nthat allow a simple configuration to fulfill the need of these users\nwithout affecting anyone else negatively.\n\n-- \nFelipe Contreras\n"}]}