{"thread":{"id":"33899","subject":"first parent, commit graph layout, and pull merge direction","startedAt":"2013-05-22T11:50:42Z","lastAt":"2014-01-22T19:08:28Z","messageCount":69,"participants":["Andreas Krey","Junio C Hamano","John Szakmeister","Jeremy Rosen","John Keeping","Felipe Contreras","Linus Torvalds","Holger Hellmuth (IKS)","Philip Oakley","Fredrik Gustafsson","W. Trevor King","Matthieu Moy","Andreas Schwab","Eric Sunshine","Flimm"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"218163","messageId":"20130522115042.GA20649@inner.h.apk.li","threadId":"33899","inReplyTo":null,"subject":"first parent, commit graph layout, and pull merge direction","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2013-05-22T11:50:42Z","receivedAt":"2013-05-22T11:50:42Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"Hi everyone,\n\nI'm just looking into better displays of the commit graph (as\ndisplayed with gitk, smartgit, fisheye) - they tend to quickly\ndissolve into a heap of spaghetti.\n\nWe had the idea that treating the first parent specially would\nhave some advantage here - including graphically indicating which\none of the parents of a commit is the first parent. (For instance,\nby letting that line leave the commit node at the top/bottom,\nand the other(s) to the side.)\n\nA short trial showed that representing first parent chains as\nstraight lines in the graph does actually improve understandability,\nas feature branches clearly stand out as separate lines even when\nthey no longer carry a branch name.\n\nDoes any GUI already do that (treat first parent specially),\nor does anybody think of doing such? I don't quite dare to\njump into the gitk code yet.\n\nAlso, there is an implication with 'git pull': You'd expect the\nmaster branch to be a first parent line, but when I do a small\nthing directly on master and need to pull before pushing back,\nthen origin/master is merged into my branch, and thus my side\nbranch becomes the first parent line.\n\nSo, feature discussion request: Invert the parent ordering\nwhen doing git pull from upstream? Configurably so?\n\nWe actually thought about putting a restriction into our blessed\nrepo that it not only restricts to fast-forward pushed, but further\nto only allow pushing new things that have the old branch head in\nthe first parent chain.\n\nWhat do you think?\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"218199","messageId":"7v4ndukhx0.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"20130522115042.GA20649@inner.h.apk.li","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-22T18:07:07Z","receivedAt":"2013-05-22T18:07:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Krey writes:\n\n> A short trial showed that representing first parent chains as\n> straight lines in the graph does actually improve understandability,\n> as feature branches clearly stand out as separate lines even when\n> they no longer carry a branch name.\n\nIf you have a four-commit segment in your commit ancestry graph\n(time flows from left to right; turn your head 90-degrees to the\nright if you want a gitk representation):\n\n ---A--X\n \\/\n /\\\n ---B--Y\n\nwhere X and Y are both merges between A and B, having A as their\nfirst parent, how would you express such a graph with first-parent\nchain going a straight line?\n\n> Also, there is an implication with 'git pull': You'd expect the\n> master branch to be a first parent line, but when I do a small\n> thing directly on master and need to pull before pushing back,\n> then origin/master is merged into my branch, and thus my side\n> branch becomes the first parent line.\n\nDon't do that, then.\n"},{"id":"218242","messageId":"20130523090657.GB23933@inner.h.apk.li","threadId":"33899","inReplyTo":"7v4ndukhx0.fsf@alter.siamese.dyndns.org","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2013-05-23T09:06:57Z","receivedAt":"2013-05-23T09:06:57Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Wed, 22 May 2013 11:07:07 +0000, Junio C Hamano wrote:\n...\n> If you have a four-commit segment in your commit ancestry graph\n\nI never had yet. :-(\n\n> (time flows from left to right; turn your head 90-degrees to the\n> right if you want a gitk representation):\n> \n> ---A--X\n> \\/\n> /\\\n> ---B--Y\n> \n> where X and Y are both merges between A and B, having A as their\n> first parent, how would you express such a graph with first-parent\n> chain going a straight line?\n\nOf course there are multiple possible straight lines and how it looks\ndepends on the order I use the existing heads to fish them out. (That\nis, when the straight lines join, I need to bend one of them.) Assuming\nI take the one where X is on, I expect a look like\n\n-----A-------X-----\n \\ |\n +- Y--------\n | |\n-----B----+--+\n\nBranch heads that are reachable from other head are picked after those\nthat aren't reachable.\n\nThe point is to get the feature branches being displayed on separate\nlanes (and thus visibly sticking out) and not being intermingled with\nthe longer-living branches.\n\n...\n> Don't do that, then.\n\n:-) Problem is, in this case 'I' expands to about\n 1<<7 people I need to educate on this.\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"218243","messageId":"CAEBDL5WqYPYnU=YoCa2gMzcJCxeNbFmFgfWnHh=+HuouXLLsxg@mail.gmail.com","threadId":"33899","inReplyTo":"20130523090657.GB23933@inner.h.apk.li","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2013-05-23T09:48:38Z","receivedAt":"2013-05-23T09:48:38Z","isPatch":false,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Thu, May 23, 2013 at 5:06 AM, Andreas Krey wrote:\n[snip]\n> ...\n>> Don't do that, then.\n>\n> :-) Problem is, in this case 'I' expands to about\n> 1<<7 people I need to educate on this.\n\nThis is a feature of `git pull` that I really despise. I really wish\n`git pull` treated the remote as the first parent in its merge\noperation.\n\n-John\n"},{"id":"218248","messageId":"1639906933.2666673.1369303672919.JavaMail.root@openwide.fr","threadId":"33899","inReplyTo":"CAEBDL5WqYPYnU=YoCa2gMzcJCxeNbFmFgfWnHh=+HuouXLLsxg@mail.gmail.com","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Jeremy Rosen","fromEmail":"jeremy.rosen@openwide.fr","sentAt":"2013-05-23T10:07:52Z","receivedAt":"2013-05-23T10:07:52Z","isPatch":false,"sender":{"key":"jeremy.rosen@openwide.fr","avatar":null},"body":"\n----- Mail original -----\n> On Thu, May 23, 2013 at 5:06 AM, Andreas Krey wrote:\n> [snip]\n> > ...\n> >> Don't do that, then.\n> >\n> > :-) Problem is, in this case 'I' expands to about\n> > 1<<7 people I need to educate on this.\n> \n> This is a feature of `git pull` that I really despise. I really wish\n> `git pull` treated the remote as the first parent in its merge\n> operation.\n> \n\nseconded...\n\ngithub's network pages (which display the commit graph of projects) seems to follow the \"first parent at the top\" rule and the pull merges are standing out as \"wrong\" because of that...\n"},{"id":"218249","messageId":"20130523102959.GP9448@inner.h.apk.li","threadId":"33899","inReplyTo":"CAEBDL5WqYPYnU=YoCa2gMzcJCxeNbFmFgfWnHh=+HuouXLLsxg@mail.gmail.com","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2013-05-23T10:29:59Z","receivedAt":"2013-05-23T10:29:59Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Thu, 23 May 2013 05:48:38 +0000, John Szakmeister wrote:\n...\n> This is a feature of `git pull` that I really despise. I really wish\n> `git pull` treated the remote as the first parent in its merge\n> operation.\n\nI'd actually only like it that way when pulling from\nthe tracking branch, not for any pull.\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"218256","messageId":"20130523110839.GT27005@serenity.lan","threadId":"33899","inReplyTo":"20130523102959.GP9448@inner.h.apk.li","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-23T11:08:39Z","receivedAt":"2013-05-23T11:08:39Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Thu, May 23, 2013 at 12:29:59PM +0200, Andreas Krey wrote:\n> On Thu, 23 May 2013 05:48:38 +0000, John Szakmeister wrote:\n> ...\n> > This is a feature of `git pull` that I really despise. I really wish\n> > `git pull` treated the remote as the first parent in its merge\n> > operation.\n> \n> I'd actually only like it that way when pulling from\n> the tracking branch, not for any pull.\n\nI'll add my voice to the \"annoyed by this\" pile ;-)\n\nI've been annoyed by this at $DAYJOB recently. A lot of people seem to\nblindly \"git pull\" without much thought about how the history is ending\nup and what they actually want to do.\n\nI wonder if it would make sense for \"git pull\" (with no arguments) to\npass \"--ff-only\" to git-merge, allowing this to be overridden with\n--rebase and --merge (which doesn't currently exist). With some\nsuitable advice output we could hopefully educate users about how to\nshape their history.\n"},{"id":"218257","messageId":"CAMP44s2zR7qYp58M_TqUqRNW24Ap5m5DsH4WWuHD3MiBu2Wg0A@mail.gmail.com","threadId":"33899","inReplyTo":"20130522115042.GA20649@inner.h.apk.li","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-23T11:34:38Z","receivedAt":"2013-05-23T11:34:38Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 22, 2013 at 6:50 AM, Andreas Krey wrote:\n> Hi everyone,\n>\n> I'm just looking into better displays of the commit graph (as\n> displayed with gitk, smartgit, fisheye) - they tend to quickly\n> dissolve into a heap of spaghetti.\n>\n> We had the idea that treating the first parent specially would\n> have some advantage here - including graphically indicating which\n> one of the parents of a commit is the first parent. (For instance,\n> by letting that line leave the commit node at the top/bottom,\n> and the other(s) to the side.)\n\nI don't understand; gitk already shows the first parent starting from\nthe bottom, and the merge commits arrive from the right side. What am\nI missing?\n\n-- \nFelipe Contreras\n"},{"id":"218259","messageId":"20130523122143.GQ9448@inner.h.apk.li","threadId":"33899","inReplyTo":"CAMP44s2zR7qYp58M_TqUqRNW24Ap5m5DsH4WWuHD3MiBu2Wg0A@mail.gmail.com","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2013-05-23T12:21:43Z","receivedAt":"2013-05-23T12:21:43Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Thu, 23 May 2013 06:34:38 +0000, Felipe Contreras wrote:\n...\n> I don't understand; gitk already shows the first parent starting from\n> the bottom, and the merge commits arrive from the right side. What am\n> I missing?\n\nThat this isn't (consistently) the case in complicated situations.\nI'll need to make a picture (as in png).\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"218279","messageId":"7vd2shheic.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"20130523110839.GT27005@serenity.lan","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-23T16:01:15Z","receivedAt":"2013-05-23T16:01:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping writes:\n\n> I've been annoyed by this at $DAYJOB recently. A lot of people seem to\n> blindly \"git pull\" without much thought about how the history is ending\n> up and what they actually want to do.\n\nI think these two are essentially the same thing, and having an\noption to flip the heads of a merge only solves a half of the\nproblem.\n\nA merge that shows everybody else's work merged into your history\nmeans you are the integrator, the keeper of the main history. And\nthe first-parent view of the history is useful only when the keeper\nof the main history takes good care of the main history.\n\nWhen you are using a \"central shared repository\" workflow, if you\nhad and used an option to flip the heads of a merge to record what\nyou have done so far as a side branch of what everybody else did to\ndo the merge, or if you rebased your work on top of what everybody\nelse did, the first-parent view would make a bit more sense than\nwhat you currently get. At least, everybody else's work will not\nappear as a side branch that does 47 unrelated things, and your work\nwill appear as a side branch. That is a big plus.\n\nBut the other half of the problem still remains, i.e. \"what they\nactually want to do\". People tend to do too many \"pull\" when their\nwork is not ready, only to \"catch up\", and that is the real problem.\n\nInstead of having a nice \"these six commits marked as 'x' were done\non a branch forked some time ago, to address only this one issue and\nto address it fully\" history that explains how these commits were\nrelated and these commits are the full solution to a single issue:\n\n x---x---x---x---x---x\n / \\\n ---o---o---o---o---o---o---M---o---o---...\n\nthey end up with something like this, even with the \"flip the heads\nof a merge\" option, by pulling too often:\n\n x---x x---x---x x\n / \\ / \\ / \\\n ---o---o---M---o---o---M---M---o---o---...\n\nThe result fragments otherwise a logical and clean \"single strand of\npearls to fully address the issue, consisting of 6 commits\", into\nseparate and seemingly unrelated pieces.\n\nImagine that other people are working the same way, and the commits\nmarked with 'o' are merges of side branches they add their half-way\nwork to the main history similar to what happened in the second\nillustration above. You would get this history:\n\n x---x x---x---x x\n / \\ / \\ / \\\n ---o---o---M---o---M---M---M---o---o---...\n \\ /\n y---y \n\nNothing, other than the labels I used in the picture, ties these\n'x's together while differentiating them from 'y's, so you lost an\nimportant information. Unless people stop doing that too many\n\"pull\"s that are used only to \"catch up\", even with the \"flip the\nheads of a merge\" option, you will not get a history that yields a\ngood first-parent view.\n\nThat gets back to what I said in the second paragraph of this\nmessage. When you \"pull\" from the central shared repository, with\nthe \"flip the heads of a merge\" option, you are acting as the keeper\nof the main history at that point, and you are responsible for\ntaking good care of it. If you make a 2+3+1=6 mess as depicted in\nthe last illustration above, you are failing to do so.\n\nOne obvious way to solve it is to use a topic branch workflow (the\nfirst picture above; 'x's are built not on local 'master'), and you\ndo a \"git pull\" from the shared repository while you are on your\n'master', which is free of your 'x's until that 6-commit series is\ncomplete and ready. Then you locally merge that topic branch and\npush it back for everybody to see, which will give you the first\npicture in this message. Incidentally, this does not need the \"flip\nthe heads\" option.\n\nSolving half a problem is better than solving no problem, and\nespecially because not all changes need to be multi-commit series\nbut can be done directly, perfectly and fully on the local 'master'\n(i.e. 2+3+1=6 split would not happen for such changes). For these\nreasons, I personally am not strongly opposed to a \"flip the heads\"\noption, if implemented cleanly.\n\nBut people need to realize that it is not solving the other half, a\nmore fundamental problem some people have in their workflow.\n"},{"id":"218280","messageId":"20130523164114.GV27005@serenity.lan","threadId":"33899","inReplyTo":"7vd2shheic.fsf@alter.siamese.dyndns.org","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-23T16:41:14Z","receivedAt":"2013-05-23T16:41:14Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Thu, May 23, 2013 at 09:01:15AM -0700, Junio C Hamano wrote:\n> John Keeping writes:\n> \n> > I've been annoyed by this at $DAYJOB recently. A lot of people seem to\n> > blindly \"git pull\" without much thought about how the history is ending\n> > up and what they actually want to do.\n> \n> I think these two are essentially the same thing, and having an\n> option to flip the heads of a merge only solves a half of the\n> problem.\n> \n> A merge that shows everybody else's work merged into your history\n> means you are the integrator, the keeper of the main history. And\n> the first-parent view of the history is useful only when the keeper\n> of the main history takes good care of the main history.\n> \n> When you are using a \"central shared repository\" workflow, if you\n> had and used an option to flip the heads of a merge to record what\n> you have done so far as a side branch of what everybody else did to\n> do the merge, or if you rebased your work on top of what everybody\n> else did, the first-parent view would make a bit more sense than\n> what you currently get. At least, everybody else's work will not\n> appear as a side branch that does 47 unrelated things, and your work\n> will appear as a side branch. That is a big plus.\n> \n> But the other half of the problem still remains, i.e. \"what they\n> actually want to do\". People tend to do too many \"pull\" when their\n> work is not ready, only to \"catch up\", and that is the real problem.\n...\n> One obvious way to solve it is to use a topic branch workflow (the\n> first picture above; 'x's are built not on local 'master'), and you\n> do a \"git pull\" from the shared repository while you are on your\n> 'master', which is free of your 'x's until that 6-commit series is\n> complete and ready. Then you locally merge that topic branch and\n> push it back for everybody to see, which will give you the first\n> picture in this message. Incidentally, this does not need the \"flip\n> the heads\" option.\n\nYes, I don't think this is as much of a problem when using a topic\nbranch workflow, because it's clear what the history should look like\nand users are expected to get it right.\n\nWhere I see this is when people are aiming for a linear history but\ndon't get that because with \"git pull\" to catch up they end up with\nthese backwards merges. In these cases, I think what users really want\nis \"git pull --rebase\".\n\nI have to wonder how often \"git pull\" with no arguments actually does\nwhat users really want (even if they don't know it!) when it doesn't\nresult in a fast-forward (and pull.rebase isn't configured).\n\nHence my suggestion to error when \"git pull\" doesn't result in a\nfast-forward and no branch name is specified. We could give some advice\nlike:\n\n Your local changes are not included in the local branch and you\n haven't told Git how to preserve them.\n\n If you want to rebase your changes onto the modified upstream\n branch, run:\n\n git pull --rebase\n\n> Solving half a problem is better than solving no problem, and\n> especially because not all changes need to be multi-commit series\n> but can be done directly, perfectly and fully on the local 'master'\n> (i.e. 2+3+1=6 split would not happen for such changes). For these\n> reasons, I personally am not strongly opposed to a \"flip the heads\"\n> option, if implemented cleanly.\n> \n> But people need to realize that it is not solving the other half, a\n> more fundamental problem some people have in their workflow.\n\nYes, but some users don't realise that their workflow is broken, and\nperhaps we can nudge them in the right direction.\n"},{"id":"218300","messageId":"20130523192512.GR9448@inner.h.apk.li","threadId":"33899","inReplyTo":"20130523090657.GB23933@inner.h.apk.li","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2013-05-23T19:25:12Z","receivedAt":"2013-05-23T19:25:12Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Thu, 23 May 2013 11:06:57 +0000, Andreas Krey wrote:\n...\n> ...\n> > Don't do that, then.\n\nOuch, you're right. The problem is not actually in the\npull; only the *last* pull into a feature branch that\nthen get pushed back ff to master needs to be reversed.\n\nAnd at that time you don't know it's the last one\n-> swap parents before the push if necessary.\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"218307","messageId":"7vbo81e7gs.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"20130523164114.GV27005@serenity.lan","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-23T21:01:39Z","receivedAt":"2013-05-23T21:01:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping writes:\n\n> I have to wonder how often \"git pull\" with no arguments actually does\n> what users really want (even if they don't know it!) when it doesn't\n> result in a fast-forward (and pull.rebase isn't configured).\n\nIf you are in a totally centralized shared repository mindset\nwithout using topic branch workflow, --first-parent would not help\nyou. In your history the second parent is more likely to be the\nmainline.\n\nSo for them \"git pull\" that either fast-forward when it can, or\nmakes a merge that records the then-current state of the central\nshared repository, is perfectly sensible. They will view gitk and\nsee all the changes, \"git shortlog\" and \"git log --no-merges\" will\ngive them what they expect.\n\n> Hence my suggestion to error when \"git pull\" doesn't result in a\n> fast-forward and no branch name is specified. We could give some advice\n> like:\n>\n> Your local changes are not included in the local branch and you\n> haven't told Git how to preserve them.\n>\n> If you want to rebase your changes onto the modified upstream\n> branch, run:\n>\n> git pull --rebase\n\nI can parse the first paragraph above, but cannot make much sense\nout of it. Unless you are talking about local changes that are not\ncommitted yet, that is. But in that case I fail to see what it has\nto do with the current discussion, or suggestion to use rebase.\n\n>> But people need to realize that it is not solving the other half, a\n>> more fundamental problem some people have in their workflow.\n>\n> Yes, but some users don't realise that their workflow is broken, and\n> perhaps we can nudge them in the right direction.\n\nI actually avoided mentioning that deliberately, because I think the\n\"flip the head when merging\" encourages people to (1) work directly\non 'master' and (2) pull too often when they shouldn't.\n\nThat is detrimental if your goal is to nudge them in the right\ndirection.\n"},{"id":"218320","messageId":"20130523215557.GX27005@serenity.lan","threadId":"33899","inReplyTo":"7vbo81e7gs.fsf@alter.siamese.dyndns.org","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-23T21:55:57Z","receivedAt":"2013-05-23T21:55:57Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Thu, May 23, 2013 at 02:01:39PM -0700, Junio C Hamano wrote:\n> John Keeping writes:\n> \n> > I have to wonder how often \"git pull\" with no arguments actually does\n> > what users really want (even if they don't know it!) when it doesn't\n> > result in a fast-forward (and pull.rebase isn't configured).\n> \n> If you are in a totally centralized shared repository mindset\n> without using topic branch workflow, --first-parent would not help\n> you. In your history the second parent is more likely to be the\n> mainline.\n> \n> So for them \"git pull\" that either fast-forward when it can, or\n> makes a merge that records the then-current state of the central\n> shared repository, is perfectly sensible. They will view gitk and\n> see all the changes, \"git shortlog\" and \"git log --no-merges\" will\n> give them what they expect.\n\nYes, but for people used to a cleaner history it's confusing to see the\nmainline branch and one small change the wrong way round. When I see\npeople doing this, it's normally something like:\n\n ... do some work for several hours...\n git commit -a\n git push\n # fails because it's not a fast forward\n git pull\n git push\n\nIn this scenario, just adding --rebase to \"git pull\" actually results in\na much more sensible history.\n\n> > Hence my suggestion to error when \"git pull\" doesn't result in a\n> > fast-forward and no branch name is specified. We could give some advice\n> > like:\n> >\n> > Your local changes are not included in the local branch and you\n> > haven't told Git how to preserve them.\n> >\n> > If you want to rebase your changes onto the modified upstream\n> > branch, run:\n> >\n> > git pull --rebase\n> \n> I can parse the first paragraph above, but cannot make much sense\n> out of it. Unless you are talking about local changes that are not\n> committed yet, that is. But in that case I fail to see what it has\n> to do with the current discussion, or suggestion to use rebase.\n\nThis isn't about \"swap parents\", it's about helping people realise that\njust \"git pull\" isn't necessarily the best thing for them to do, and\nthat they may want --rebase.\n\nSo I was asking if it would be sensible (possibly in Git 2.0) to make\ngit-pull pass --ff-only to git-merge by default.\n"},{"id":"218322","messageId":"CAMP44s3hyekQBxV13=+4qcJEMZe4TY6ZoMMDLN8yKFJJ=t_7rA@mail.gmail.com","threadId":"33899","inReplyTo":"20130523215557.GX27005@serenity.lan","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-23T21:59:34Z","receivedAt":"2013-05-23T21:59:34Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 23, 2013 at 4:55 PM, John Keeping wrote:\n\n> So I was asking if it would be sensible (possibly in Git 2.0) to make\n> git-pull pass --ff-only to git-merge by default.\n\nDefinitely yes.\n\n-- \nFelipe Contreras\n"},{"id":"218324","messageId":"7vli75cpom.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"20130523215557.GX27005@serenity.lan","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-23T22:11:05Z","receivedAt":"2013-05-23T22:11:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping writes:\n\n> This isn't about \"swap parents\", it's about helping people realise that\n> just \"git pull\" isn't necessarily the best thing for them to do, and\n> that they may want --rebase.\n>\n> So I was asking if it would be sensible (possibly in Git 2.0) to make\n> git-pull pass --ff-only to git-merge by default.\n\nUnless your primary user base is those who use Git as a deployment\ntool to always follow along the tip of some external repository\nwithout doing anything on your own on the branch you run your \"git\npull\" on, defaulting it to --ff-only does not make much sense to me.\n\nIf the proposal were to make pull.rebase the default at a major\nversion bump and force all integrators and other people who are\nhappy with how \"pull = fetch + merge\" (not \"fetch + rebase\") works\nto say \"pull.rebase = false\" in their configuration, I think I can\nsee why some people may think it makes sense, though.\n\nBut neither is an easy sell, I would imagine. It is not about\npassing me, but about not hurting users like kernel folks we\naccumulated over 7-8 years.\n\nAlso \"rebase\" of the branch you attempted to push out is sometimes a\ngood solution (fixing \"just a small change on 'master'\" that was\nbeaten by somebody else pushing first), but is a bad workaround (you\nhad many changes on that branch, which would have been better if\nthey were done on a topic branch, but you do not want to merge with\nthe upstream because you worked on 'master') some other times, so I\nhave this suspicion that 'pull.rebase' is not necessarily a good\nthing to encourage in the first place.\n"},{"id":"218326","messageId":"CAMP44s3-3gpAAyp-WfDjHxJiotO68GUbb5tHw9Qo35yCTGFNqA@mail.gmail.com","threadId":"33899","inReplyTo":"7vli75cpom.fsf@alter.siamese.dyndns.org","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-23T22:46:19Z","receivedAt":"2013-05-23T22:46:19Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano wrote:\n> John Keeping writes:\n>\n>> This isn't about \"swap parents\", it's about helping people realise that\n>> just \"git pull\" isn't necessarily the best thing for them to do, and\n>> that they may want --rebase.\n>>\n>> So I was asking if it would be sensible (possibly in Git 2.0) to make\n>> git-pull pass --ff-only to git-merge by default.\n>\n> Unless your primary user base is those who use Git as a deployment\n> tool to always follow along the tip of some external repository\n> without doing anything on your own on the branch you run your \"git\n> pull\" on, defaulting it to --ff-only does not make much sense to me.\n\nA lot of people do stuff, but the rebase it.\n\n> If the proposal were to make pull.rebase the default at a major\n> version bump and force all integrators and other people who are\n> happy with how \"pull = fetch + merge\" (not \"fetch + rebase\") works\n> to say \"pull.rebase = false\" in their configuration, I think I can\n> see why some people may think it makes sense, though.\n\nThat makes perfect sense, because the people that are not familiar\nwith Git more often than not end up making merges by mistake, and the\nones that are familiar with it can easily configure it to do what they\nwant, or just 'git pull --merge', or 'git fetch'+'git merge' (we\nshould make merge.defaulttoupstream=true as well).\n\n> But neither is an easy sell, I would imagine. It is not about\n> passing me, but about not hurting users like kernel folks we\n> accumulated over 7-8 years.\n\nI've worked in the Linux kernel, and in my experience the vast vast\nmajority of kernel developers don't do merges; they send patches. It's\nonly the lieutenants that might do that, and although there are a lot,\nthey don't surpass the 200, and they most definitely know how to\nconfigure Git to do what they need. And even then, most of them don't\ndo merges, but create a linear history for Linus to merge.\n\nSo the only one who does really rely on merges is Linus, I think he\nwould have no problems configuring Git.\n\nIt is also my experience that most people don't do 'git pull', because\nit rarely does what one wants; 'upstream' is still too cumbersome for\nmost people.\n\n> Also \"rebase\" of the branch you attempted to push out is sometimes a\n> good solution (fixing \"just a small change on 'master'\" that was\n> beaten by somebody else pushing first), but is a bad workaround (you\n> had many changes on that branch, which would have been better if\n> they were done on a topic branch, but you do not want to merge with\n> the upstream because you worked on 'master') some other times, so I\n> have this suspicion that 'pull.rebase' is not necessarily a good\n> thing to encourage in the first place.\n\nToo bad, that's what most people recommend; 'git fetch'+'git rebase'.\nThat's the only way newcomers can avoid the ugliness of 'upstream',\nand avoid making atrocious merges.\n\nIt's silly that the people familiar with Git has to explain this to\neach and every newcomer.\n\n-- \nFelipe Contreras\n"},{"id":"218328","messageId":"7v8v35cnp0.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"CAMP44s3-3gpAAyp-WfDjHxJiotO68GUbb5tHw9Qo35yCTGFNqA@mail.gmail.com","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-23T22:54:03Z","receivedAt":"2013-05-23T22:54:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano wrote:\n>> John Keeping writes:\n>>\n>>> This isn't about \"swap parents\", it's about helping people realise that\n>>> just \"git pull\" isn't necessarily the best thing for them to do, and\n>>> that they may want --rebase.\n>>>\n>>> So I was asking if it would be sensible (possibly in Git 2.0) to make\n>>> git-pull pass --ff-only to git-merge by default.\n>>\n>> Unless your primary user base is those who use Git as a deployment\n>> tool to always follow along the tip of some external repository\n>> without doing anything on your own on the branch you run your \"git\n>> pull\" on, defaulting it to --ff-only does not make much sense to me.\n>\n> A lot of people do stuff, but the rebase it.\n\nIf I am parsing the above properly, I think that is only saying that\n\"pull --rebase\" makes sense for people who do real work, which I am\nnot disagreeing.\n\n>> If the proposal were to make pull.rebase the default at a major\n>> version bump and force all integrators and other people who are\n>> happy with how \"pull = fetch + merge\" (not \"fetch + rebase\") works\n>> to say \"pull.rebase = false\" in their configuration, I think I can\n>> see why some people may think it makes sense, though.\n>\n> That makes perfect sense, because the people that are not familiar\n> with Git more often than not end up making merges by mistake, and the\n> ones that are familiar with it can easily configure it to do what they\n> want\n\nYes, in theory. The transition needs a major version bump, but it\nis doable (with unknown level of resistance).\n\n>> But neither is an easy sell, I would imagine. It is not about\n>> passing me, but about not hurting users like kernel folks we\n>> accumulated over 7-8 years.\n>\n> I've worked in the Linux kernel, and in my experience the vast vast\n> majority of kernel developers don't do merges; they send patches. It's\n> only the lieutenants that might do that, and although there are a lot,\n> they don't surpass the 200, and they most definitely know how to\n> configure Git to do what they need. And even then, most of them don't\n> do merges, but create a linear history for Linus to merge.\n>\n> So the only one who does really rely on merges is Linus, I think he\n> would have no problems configuring Git.\n\nThat is not something I can agree or disagree without looping\nsomebody whose judgement I can trust from the kernel circle ;-).\n"},{"id":"218331","messageId":"CAMP44s1N=xy2B-YkCLC67pX_EVqAziGWyN1qkrs0Sq=o2jL6Sw@mail.gmail.com","threadId":"33899","inReplyTo":"7v8v35cnp0.fsf@alter.siamese.dyndns.org","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-23T23:09:30Z","receivedAt":"2013-05-23T23:09:30Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 23, 2013 at 5:54 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>> On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano wrote:\n>>> John Keeping writes:\n>>>\n>>>> This isn't about \"swap parents\", it's about helping people realise that\n>>>> just \"git pull\" isn't necessarily the best thing for them to do, and\n>>>> that they may want --rebase.\n>>>>\n>>>> So I was asking if it would be sensible (possibly in Git 2.0) to make\n>>>> git-pull pass --ff-only to git-merge by default.\n>>>\n>>> Unless your primary user base is those who use Git as a deployment\n>>> tool to always follow along the tip of some external repository\n>>> without doing anything on your own on the branch you run your \"git\n>>> pull\" on, defaulting it to --ff-only does not make much sense to me.\n>>\n>> A lot of people do stuff, but the rebase it.\n>\n> If I am parsing the above properly, I think that is only saying that\n> \"pull --rebase\" makes sense for people who do real work, which I am\n> not disagreeing.\n\nYou claimed that 'git pull' (--ff-only) only makes sense if the\nprimary user-base doesn't do any work on it, but that's not true; they\ncan do a 'git rebase' after such pull (or a merge).\n\nWe don't have to assume our primary user-base wants to do full fledged\nmerges, in fact, such assumption would be wrong.\n\n>>> If the proposal were to make pull.rebase the default at a major\n>>> version bump and force all integrators and other people who are\n>>> happy with how \"pull = fetch + merge\" (not \"fetch + rebase\") works\n>>> to say \"pull.rebase = false\" in their configuration, I think I can\n>>> see why some people may think it makes sense, though.\n>>\n>> That makes perfect sense, because the people that are not familiar\n>> with Git more often than not end up making merges by mistake, and the\n>> ones that are familiar with it can easily configure it to do what they\n>> want\n>\n> Yes, in theory. The transition needs a major version bump, but it\n> is doable (with unknown level of resistance).\n\nIsn't that what wer are discussing here?\n\n>>> But neither is an easy sell, I would imagine. It is not about\n>>> passing me, but about not hurting users like kernel folks we\n>>> accumulated over 7-8 years.\n>>\n>> I've worked in the Linux kernel, and in my experience the vast vast\n>> majority of kernel developers don't do merges; they send patches. It's\n>> only the lieutenants that might do that, and although there are a lot,\n>> they don't surpass the 200, and they most definitely know how to\n>> configure Git to do what they need. And even then, most of them don't\n>> do merges, but create a linear history for Linus to merge.\n>>\n>> So the only one who does really rely on merges is Linus, I think he\n>> would have no problems configuring Git.\n>\n> That is not something I can agree or disagree without looping\n> somebody whose judgement I can trust from the kernel circle ;-).\n\nSee section 16) in Documentation/SubmittingPatches, notice how the\nwhole section is written with Linus in mind. Some maintainers do have\nsub-maintainers that send pull requests to them, not Linus, but they\nare the minority. But most definitely pull requests are not for the\ngeneral population (except in a few very rare exceptions maybe).\n\n-- \nFelipe Contreras\n"},{"id":"218333","messageId":"7vzjvlb7mu.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"CAMP44s1N=xy2B-YkCLC67pX_EVqAziGWyN1qkrs0Sq=o2jL6Sw@mail.gmail.com","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-23T23:26:17Z","receivedAt":"2013-05-23T23:26:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n>>>> Unless your primary user base is those who use Git as a deployment\n>>>> tool to always follow along the tip of some external repository\n>>>> without doing anything on your own on the branch you run your \"git\n>>>> pull\" on, defaulting it to --ff-only does not make much sense to me.\n>>>\n>>> A lot of people do stuff, but the rebase it.\n>>\n>> If I am parsing the above properly, I think that is only saying that\n>> \"pull --rebase\" makes sense for people who do real work, which I am\n>> not disagreeing.\n>\n> You claimed that 'git pull' (--ff-only) only makes sense if the\n> primary user-base doesn't do any work on it, but that's not true; they\n> can do a 'git rebase' after such pull (or a merge).\n\nEither you misread what I wrote or I was unclear. I really meant\n\"anything on your own *ON* THE BRANCH YOU RUN your \"git pull\" on\".\nWith\n\n\tgit checkout frotz ; git pull --ff-only\n\nyou do not do anything \"on frotz\" other than following along. You\ncan of course commit, rebase and all others on other branches like\nxyzzy and push them out directly. But you cannot even do this once\n\n\tgit checkout frotz; git merge xyzzy\n\nif you expect the next \"git checkout frotz; git pull --ff-only\" will\nkeep working usefuly.\n\n\n> We don't have to assume our primary user-base wants to do full fledged\n> merges, in fact, such assumption would be wrong.\n\nI think we are in agreement on that point already.\n\nAn assumption that people who do merges are somehow more well versed\nin Git and are more capable than others to configure their\nrepository or they will not be annoyed if you asked them a single\nconfiguration change is also wrong, though.\n"},{"id":"218336","messageId":"CAMP44s1D06ggmTjXBEL0puFLqYDShhy6HV0S+oj0AwDGz-sUqA@mail.gmail.com","threadId":"33899","inReplyTo":"7vzjvlb7mu.fsf@alter.siamese.dyndns.org","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-23T23:53:36Z","receivedAt":"2013-05-23T23:53:36Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 23, 2013 at 6:26 PM, Junio C Hamano wrote:\n> Felipe Contreras writes:\n>\n>>>>> Unless your primary user base is those who use Git as a deployment\n>>>>> tool to always follow along the tip of some external repository\n>>>>> without doing anything on your own on the branch you run your \"git\n>>>>> pull\" on, defaulting it to --ff-only does not make much sense to me.\n>>>>\n>>>> A lot of people do stuff, but the rebase it.\n>>>\n>>> If I am parsing the above properly, I think that is only saying that\n>>> \"pull --rebase\" makes sense for people who do real work, which I am\n>>> not disagreeing.\n>>\n>> You claimed that 'git pull' (--ff-only) only makes sense if the\n>> primary user-base doesn't do any work on it, but that's not true; they\n>> can do a 'git rebase' after such pull (or a merge).\n>\n> Either you misread what I wrote or I was unclear. I really meant\n> \"anything on your own *ON* THE BRANCH YOU RUN your \"git pull\" on\".\n> With\n>\n> git checkout frotz ; git pull --ff-only\n>\n> you do not do anything \"on frotz\" other than following along. You\n> can of course commit, rebase and all others on other branches like\n> xyzzy and push them out directly. But you cannot even do this once\n>\n> git checkout frotz; git merge xyzzy\n>\n> if you expect the next \"git checkout frotz; git pull --ff-only\" will\n> keep working usefuly.\n\nUnless you rebase. We could of course have a\n'branch..allow_merge' configuration that gets automatically\nturned on the first time a 'git merge' is executed, but I feel that\ncreates more inconsistency.\n\n>> We don't have to assume our primary user-base wants to do full fledged\n>> merges, in fact, such assumption would be wrong.\n>\n> I think we are in agreement on that point already.\n>\n> An assumption that people who do merges are somehow more well versed\n> in Git and are more capable than others to configure their\n> repository or they will not be annoyed if you asked them a single\n> configuration change is also wrong, though.\n\ns/people who do merges/people who should do merges/\n\nAnd no, it's not wrong. People who do merges should know what they are doing.\n\nThe alternatives are these:\n\na) you annoy the vast majority of the user-base by making 'git pull' a\ndangerous operation that should be avoided, and replaced with 'git\nfetch'+'git rebase'.\n\nb) you annoy a minority of the user-base by making 'git pull' not do\nthe merge the expected, so they have to do +'git merge' (which is\nalready less of a change than a)), or configure the default (which\nthey most likely are able to do, if they did intent to do a merge).\n\nb) is clearly superior.\n\n-- \nFelipe Contreras\n"},{"id":"218337","messageId":"CA+55aFz2Uvq4vmyjJPao5tS-uuVvKm6mbP7Uz8sdq1VMxMGJCw@mail.gmail.com","threadId":"33899","inReplyTo":"7vli75cpom.fsf@alter.siamese.dyndns.org","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2013-05-24T00:03:38Z","receivedAt":"2013-05-24T00:03:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Thu, May 23, 2013 at 3:11 PM, Junio C Hamano wrote:\n>\n> If the proposal were to make pull.rebase the default at a major\n> version bump and force all integrators and other people who are\n> happy with how \"pull = fetch + merge\" (not \"fetch + rebase\") works\n> to say \"pull.rebase = false\" in their configuration, I think I can\n> see why some people may think it makes sense, though.\n>\n> But neither is an easy sell, I would imagine. It is not about\n> passing me, but about not hurting users like kernel folks we\n> accumulated over 7-8 years.\n\nIt would be a *horrible* mistake to make \"rebase\" the default, because\nit's so much easier to screw things up that way.\n\nThat said, making \"no-ff\" the default, and then if that fails, saying\n\n The pull was not a fast-forward pull, please say if you want to\nmerge or rebase.\n Use either\n\n git pull --rebase\n git pull --merge\n\n You can also use \"git config pull.merge true\" or \"git config\npull.rebase true\"\n to set this once for this project and forget about it.\n\nThat way, people who want the existing behavior could just do that\n\n git config pull.merge true\n\nonce, and they'd not even notice.\n\nHmm? Better yet, make it per-branch.\n\n Linus\n"},{"id":"218339","messageId":"7vppwhb52f.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"CA+55aFz2Uvq4vmyjJPao5tS-uuVvKm6mbP7Uz8sdq1VMxMGJCw@mail.gmail.com","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-24T00:21:44Z","receivedAt":"2013-05-24T00:21:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> It would be a *horrible* mistake to make \"rebase\" the default, because\n> it's so much easier to screw things up that way.\n>\n> That said, making \"no-ff\" the default, and then if that fails, saying\n>\n> The pull was not a fast-forward pull, please say if you want to\n> merge or rebase.\n> Use either\n>\n> git pull --rebase\n> git pull --merge\n>\n> You can also use \"git config pull.merge true\" or \"git config\n> pull.rebase true\"\n> to set this once for this project and forget about it.\n>\n> That way, people who want the existing behavior could just do that\n>\n> git config pull.merge true\n>\n> once, and they'd not even notice.\n>\n> Hmm? Better yet, make it per-branch.\n\nI would assume that \"no-ff\" above was meant to be \"--ff-only\" from\nthe first part of the message.\n\nI also would assume that I can rephrase that setting pull.merge\n(which does not exist) as setting pull.rebase explicitly to false\ninstead (i.e. missing pull.rebase and pull.rebase that is explicitly\nset to false would mean two different things).\n\nI have to think about this a bit to convince myself that the message\nis clear enough and useful for those this updated behaviour is\ntrying to help. After reading the above message three times, I\nstill cannot shake the impression that we are just covering our\nbackside to be able to say \"we told you already and you chose\npoorly\", in case things go wrong for them later.\n"},{"id":"218341","messageId":"CA+55aFzpT8b1E9PxJmCmfEg3k7yMX7iRcQQebV_6ZmwCwgqb9w@mail.gmail.com","threadId":"33899","inReplyTo":"7vppwhb52f.fsf@alter.siamese.dyndns.org","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2013-05-24T00:24:04Z","receivedAt":"2013-05-24T00:24:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Thu, May 23, 2013 at 5:21 PM, Junio C Hamano wrote:\n>\n> I would assume that \"no-ff\" above was meant to be \"--ff-only\" from\n> the first part of the message.\n\nYeah, I may need more coffee..\n\n> I also would assume that I can rephrase that setting pull.merge\n> (which does not exist) as setting pull.rebase explicitly to false\n> instead (i.e. missing pull.rebase and pull.rebase that is explicitly\n> set to false would mean two different things).\n\nYeah, sounds good to me, and doesn't really sound like it would\nconfuse/annoy anybody as long as it was clearly documented.\n\n Linus\n"},{"id":"218342","messageId":"CAMP44s0NmKO7qkxVDMqR7Lxutm19MdOQ+6u5_3MY6f18C_V3PA@mail.gmail.com","threadId":"33899","inReplyTo":"7vppwhb52f.fsf@alter.siamese.dyndns.org","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-24T00:25:53Z","receivedAt":"2013-05-24T00:25:53Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 23, 2013 at 7:21 PM, Junio C Hamano wrote:\n> Linus Torvalds writes:\n>\n>> It would be a *horrible* mistake to make \"rebase\" the default, because\n>> it's so much easier to screw things up that way.\n>>\n>> That said, making \"no-ff\" the default, and then if that fails, saying\n>>\n>> The pull was not a fast-forward pull, please say if you want to\n>> merge or rebase.\n>> Use either\n>>\n>> git pull --rebase\n>> git pull --merge\n>>\n>> You can also use \"git config pull.merge true\" or \"git config\n>> pull.rebase true\"\n>> to set this once for this project and forget about it.\n>>\n>> That way, people who want the existing behavior could just do that\n>>\n>> git config pull.merge true\n>>\n>> once, and they'd not even notice.\n>>\n>> Hmm? Better yet, make it per-branch.\n>\n> I would assume that \"no-ff\" above was meant to be \"--ff-only\" from\n> the first part of the message.\n>\n> I also would assume that I can rephrase that setting pull.merge\n> (which does not exist) as setting pull.rebase explicitly to false\n> instead (i.e. missing pull.rebase and pull.rebase that is explicitly\n> set to false would mean two different things).\n>\n> I have to think about this a bit to convince myself that the message\n> is clear enough and useful for those this updated behaviour is\n> trying to help. After reading the above message three times, I\n> still cannot shake the impression that we are just covering our\n> backside to be able to say \"we told you already and you chose\n> poorly\", in case things go wrong for them later.\n\nFWIW this is the message Mercurial users get (and they often say\nMercurial's UI makes more sense):\n\npushing to /tmp/foo\nsearching for changes\nabort: push creates new remote head 77eafc4313d5!\n(you should pull and merge or use push -f to force)\n\n-- \nFelipe Contreras\n"},{"id":"218343","messageId":"CAMP44s3Ba7L5fvEQPo0VADzNn9pJeyr2=f+OyW+_V5kkuKqEEw@mail.gmail.com","threadId":"33899","inReplyTo":"CAMP44s0NmKO7qkxVDMqR7Lxutm19MdOQ+6u5_3MY6f18C_V3PA@mail.gmail.com","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-24T00:32:59Z","receivedAt":"2013-05-24T00:32:59Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, May 23, 2013 at 7:25 PM, Felipe Contreras\n wrote:\n> On Thu, May 23, 2013 at 7:21 PM, Junio C Hamano wrote:\n>> Linus Torvalds writes:\n>>\n>>> It would be a *horrible* mistake to make \"rebase\" the default, because\n>>> it's so much easier to screw things up that way.\n>>>\n>>> That said, making \"no-ff\" the default, and then if that fails, saying\n>>>\n>>> The pull was not a fast-forward pull, please say if you want to\n>>> merge or rebase.\n>>> Use either\n>>>\n>>> git pull --rebase\n>>> git pull --merge\n>>>\n>>> You can also use \"git config pull.merge true\" or \"git config\n>>> pull.rebase true\"\n>>> to set this once for this project and forget about it.\n>>>\n>>> That way, people who want the existing behavior could just do that\n>>>\n>>> git config pull.merge true\n>>>\n>>> once, and they'd not even notice.\n>>>\n>>> Hmm? Better yet, make it per-branch.\n>>\n>> I would assume that \"no-ff\" above was meant to be \"--ff-only\" from\n>> the first part of the message.\n>>\n>> I also would assume that I can rephrase that setting pull.merge\n>> (which does not exist) as setting pull.rebase explicitly to false\n>> instead (i.e. missing pull.rebase and pull.rebase that is explicitly\n>> set to false would mean two different things).\n>>\n>> I have to think about this a bit to convince myself that the message\n>> is clear enough and useful for those this updated behaviour is\n>> trying to help. After reading the above message three times, I\n>> still cannot shake the impression that we are just covering our\n>> backside to be able to say \"we told you already and you chose\n>> poorly\", in case things go wrong for them later.\n>\n> FWIW this is the message Mercurial users get (and they often say\n> Mercurial's UI makes more sense):\n>\n> pushing to /tmp/foo\n> searching for changes\n> abort: push creates new remote head 77eafc4313d5!\n> (you should pull and merge or use push -f to force)\n\nEr, that's for push, but I don't see why something small like that\nwouldn't make sense:\n\nThe pull was not fast-forward, please either merge or rebase.\n\n-- \nFelipe Contreras\n"},{"id":"218349","messageId":"20130524082900.GZ27005@serenity.lan","threadId":"33899","inReplyTo":"CAMP44s1D06ggmTjXBEL0puFLqYDShhy6HV0S+oj0AwDGz-sUqA@mail.gmail.com","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-05-24T08:29:01Z","receivedAt":"2013-05-24T08:29:01Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Thu, May 23, 2013 at 06:53:36PM -0500, Felipe Contreras wrote:\n> The alternatives are these:\n> \n> a) you annoy the vast majority of the user-base by making 'git pull' a\n> dangerous operation that should be avoided, and replaced with 'git\n> fetch'+'git rebase'.\n> \n> b) you annoy a minority of the user-base by making 'git pull' not do\n> the merge the expected, so they have to do +'git merge' (which is\n> already less of a change than a)), or configure the default (which\n> they most likely are able to do, if they did intent to do a merge).\n\nNote that in my email that started this, I tried to be clear that I was\ntalking about \"git pull\" *without a branch name*. If this user\nexplicitly says \"git pull remote branch\" then I consider that a clear\nindication that they really do mean to perform a merge; I would not\nrecommend changing the current behaviour in that case.\n\nIf the user just says \"git pull\" then it is more likely that they are\njust trying to synchronise with the upstream branch, in which case they\nprobably don't actually want a merge.\n"},{"id":"218350","messageId":"519F32DC.0@ira.uka.de","threadId":"33899","inReplyTo":"20130523192512.GR9448@inner.h.apk.li","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Holger Hellmuth (IKS)","fromEmail":"hellmuth@ira.uka.de","sentAt":"2013-05-24T09:29:00Z","receivedAt":"2013-05-24T09:29:00Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Am 23.05.2013 21:25, schrieb Andreas Krey:\n> On Thu, 23 May 2013 11:06:57 +0000, Andreas Krey wrote:\n> ...\n>> ...\n>>> Don't do that, then.\n>\n> Ouch, you're right. The problem is not actually in the\n> pull; only the *last* pull into a feature branch that\n> then get pushed back ff to master needs to be reversed.\n>\n> And at that time you don't know it's the last one\n> -> swap parents before the push if necessary.\n\nif you have to be so careful to ensure the correct ordering of parents \nit almost defeats the initial objective to make commit graphs in gitk \nlook nice without re-educating/restricting other users. A solution that \nworks for everyone should work without users having to think about it.\n\nHere is an idea (probably already discussed in the long history of git):\n1) the branch name is recorded in a commit (for merges the branch that \nis updated)\n2) unique identifier of repository is recorded in commit (optional)\n3) simple configurable ordering and/or coloring scheme in gitk based on \ncommitter,branch name and repo (with wildcards).\n\nWith this users could pull and push as often as they like, the main \nbranches would always be ordered and straight lines. If instead you \nalready do the work to keep your history clean you could just use the \ncoloring scheme and see committers color coded in gitk. Further benefit: \nthe history of really old commits could be more easily remembered if you \nknew in what branch they originated\n\nIs this a bad idea or just no one did it yet?\n"},{"id":"218352","messageId":"CAEBDL5VWuvuJCptY=J5ZyjpLkkP-+V+xY+Eugtkb7M0NL=Px4A@mail.gmail.com","threadId":"33899","inReplyTo":"20130524082900.GZ27005@serenity.lan","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2013-05-24T09:38:08Z","receivedAt":"2013-05-24T09:38:08Z","isPatch":false,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Fri, May 24, 2013 at 4:29 AM, John Keeping wrote:\n[snip]\n> Note that in my email that started this, I tried to be clear that I was\n> talking about \"git pull\" *without a branch name*. If this user\n> explicitly says \"git pull remote branch\" then I consider that a clear\n> indication that they really do mean to perform a merge; I would not\n> recommend changing the current behaviour in that case.\n>\n> If the user just says \"git pull\" then it is more likely that they are\n> just trying to synchronise with the upstream branch, in which case they\n> probably don't actually want a merge.\n\nThis makes a lot of sense to me. I was going to write earlier that I\nalmost wish there was a separate command for getting your local branch\n\"in sync\" with the remote one.\n\nBTW, it also doesn't help that `git pull` is suggested as the answer\nanytime a push cannot succeed. I've warned my users about using `git\npull`, and--unfortunately--they sometimes forget because the advice is\nright there in front of them.\n\nI agree with John here: it's a bare `git pull` that is often the\nculprit. Of course, the asymmetry between `git pull` and `git pull\nremote branch` is a little bothersome too, but the team does that\n*far* less often.\n\n-John\n"},{"id":"218368","messageId":"20130524134214.GA26617@inner.h.apk.li","threadId":"33899","inReplyTo":"519F32DC.0@ira.uka.de","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2013-05-24T13:42:14Z","receivedAt":"2013-05-24T13:42:14Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Fri, 24 May 2013 11:29:00 +0000, Holger Hellmuth (IKS) wrote:\n...\n> Here is an idea (probably already discussed in the long history of git):\n> 1) the branch name is recorded in a commit (for merges the branch that \n> is updated)\n\nThe branch name is almost completely meaningless. I could just\ndo my feature in my local master and never have a different name.\n\nOr commit something onto tmp that I then fast-forward into my\n(properly named) feature branch.\n\n> 2) unique identifier of repository is recorded in commit (optional)\n\nThat is pure noise (in my workflow).\n\n> 3) simple configurable ordering and/or coloring scheme in gitk based on \n> committer,branch name and repo (with wildcards).\n\nOk, gitk could use some features. :-)\n\n...\n> Is this a bad idea or just no one did it yet?\n\nPossibly not bad (hg does parts of it), but un-git-ish?\n\n(I'm not sure that it was *intended* that the parents\nof a merge commit have an order, except that they need\nto for deterministic hashes.)\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"218375","messageId":"519F81B6.4010807@ira.uka.de","threadId":"33899","inReplyTo":"20130524134214.GA26617@inner.h.apk.li","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Holger Hellmuth (IKS)","fromEmail":"hellmuth@ira.uka.de","sentAt":"2013-05-24T15:05:26Z","receivedAt":"2013-05-24T15:05:26Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Am 24.05.2013 15:42, schrieb Andreas Krey:\n> On Fri, 24 May 2013 11:29:00 +0000, Holger Hellmuth (IKS) wrote:\n> ...\n>> Here is an idea (probably already discussed in the long history of git):\n>> 1) the branch name is recorded in a commit (for merges the branch that\n>> is updated)\n>\n> The branch name is almost completely meaningless. I could just\n> do my feature in my local master and never have a different name.\n\nIn which case parent switching in the commit wouldn't help you either.\n\nBut even you could keep your master always on the left side of gitk if \nyou deem it special. And you could keep longer running cooperative \nbranches (the main develop and the release branch of your project for \nexample) in a seperate lane.\n\nDepending on your use of branches many branches won't get any ordering, \nbut at a minimum important branches can easily be \"highlighted\".\n\n> Or commit something onto tmp that I then fast-forward into my\n> (properly named) feature branch.\n\nYes, but then you would see a feature branch in its expected column in \ngitk and you would also see (even years later) that it didn't start as a \nfeature but later was made into one. Cues like this help to remember \nwhat happened even if you forgot to mention them in the commit message\n\n>> 2) unique identifier of repository is recorded in commit (optional)\n>\n> That is pure noise (in my workflow).\n\nIt is important to differentiate between branches of the same name in \ndifferent repositories. For example if your project has a central \nrepository with master getting all the release stuff you want to sort \nthat master differently than your own master.\n\nThe unique identifier might be just a random number or string created at \ninit time of the repo.\n\n>> 3) simple configurable ordering and/or coloring scheme in gitk based on\n>> committer,branch name and repo (with wildcards).\n>\n> Ok, gitk could use some features. :-)\n\nWithout additional information about the commit history gitk can do \nexactly what it does now.\n\n> ...\n>> Is this a bad idea or just no one did it yet?\n>\n> Possibly not bad (hg does parts of it), but un-git-ish?\n\nDon't know. No CVS does branches as good as git. But then it drops that \ninformation which depending on development style could be useful or not.\nNot that useful for people who keep their history clean, a lot for \npeople who don't.\n"},{"id":"218391","messageId":"7vli74baym.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"CAMP44s3Ba7L5fvEQPo0VADzNn9pJeyr2=f+OyW+_V5kkuKqEEw@mail.gmail.com","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-24T16:26:41Z","receivedAt":"2013-05-24T16:26:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> ... but I don't see why something small like that\n> wouldn't make sense:\n>\n> The pull was not fast-forward, please either merge or rebase.\n\nOK, I think I got what John was getting at and this single liner\nmessage is a good summary of it.\n\nInstead of telling them \"you cannot push this thing without losing\nhistory from the location you are pushing to; you need to become up\nto date with respect to them before pushing\" upon seeing a non ff\npush failure, we can tell them \"you cannot update your history to\nwhat the place you get new changes from has without losing your\nhistory; you need to integrate the two\".\n\nInitially I said limiting \"git pull\" to \"--ff-only\" by default did\nnot make sense, but when we view it that way, I now see how such a\ndefault makes sense.\n\nIn another subthread, John Szakmeister mentioned that the \"please\n'git pull' first\" message that a \"push\" gives when it stops due to\nnon-ff nudges the users in a wrong direction, because they often\ntake that 'git pull' too literally (e.g. 'pull --rebase' may be\nnecessary in their project, not 'git pull').\n\nThe original message deliberately avoided mentioning 'git pull' for\nthat exact reason, but in mid 2010 we made it worse. The log of\nthat change says that it attempted to\n\n ... remains fuzzy to include \"git pull\", \"git pull --rebase\" and\n others, but directs the user to the simplest solution in the\n vast majority of cases.\n\nbut this thread shows that it did not work; the simplest solution\nwas a wrong one. The message also may need to be rethought to\ncomplement this direction being proposed for \"pull\".\n"},{"id":"218397","messageId":"20130524171110.GB9448@inner.h.apk.li","threadId":"33899","inReplyTo":"7vd2shheic.fsf@alter.siamese.dyndns.org","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2013-05-24T17:11:10Z","receivedAt":"2013-05-24T17:11:10Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Thu, 23 May 2013 09:01:15 +0000, Junio C Hamano wrote:\n...\n> Instead of having a nice \"these six commits marked as 'x' were done\n> on a branch forked some time ago, to address only this one issue and\n> to address it fully\" history that explains how these commits were\n> related and these commits are the full solution to a single issue:\n> \n> x---x---x---x---x---x\n> / \\\n> ---o---o---o---o---o---o---M---o---o---...\n> \n> they end up with something like this, even with the \"flip the heads\n> of a merge\" option, by pulling too often:\n> \n> x---x x---x---x x\n> / \\ / \\ / \\\n> ---o---o---M---o---o---M---M---o---o---...\n\nWouldn't that be (you don't want to put your work back into master before\nit's done) the following?\n\n x---x---M---x---x---M--x\n / / / \\\n ---o---o---M---o---o---M--o---M---o---o---...\n\nWith a bit of luck the first-parent strands will also run like this.\n\nI know that rebasing topic branches is better than updating, but my\nmonetary upstream is busy letting go a clearcase-minted mindset.\nTeaching them rebasing will take a while, and as long as tthat we\nwill have the picture above.\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"218399","messageId":"20130524172440.GC9448@inner.h.apk.li","threadId":"33899","inReplyTo":"519F81B6.4010807@ira.uka.de","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2013-05-24T17:24:40Z","receivedAt":"2013-05-24T17:24:40Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Fri, 24 May 2013 17:05:26 +0000, Holger Hellmuth (IKS) wrote:\n> Am 24.05.2013 15:42, schrieb Andreas Krey:\n...\n> >The branch name is almost completely meaningless. I could just\n> >do my feature in my local master and never have a different name.\n> \n> In which case parent switching in the commit wouldn't help you either.\n\nOh, it does; I tried. Names are meaningless, the parent ordering\nisn't. ( [And at least, it's already in there.]\n\n> But even you could keep your master always on the left side of gitk if \n> you deem it special. And you could keep longer running cooperative \n> branches (the main develop and the release branch of your project for \n> example) in a seperate lane.\n\nI need gitk (or similar) to do it. Will take some time to understand\nthe code (and triggers the 'I can write it (the interesting part) faster\nthan I can grok gitk').\n\n...\n> Without additional information about the commit history gitk can do \n> exactly what it does now.\n\nMost definitely not. There are quite some situations where the graph\ndeteriorates pretty heavily, even when not expecting it to pay attention\nto first parent. When you have two branches, of which one regularly\ngets merge into the other, it sometimes manages to display first the\none, then the other branch, with a log of merge edges going upwards\nin parallel, for example.\n\nAndreas\n\n-- \n\"Totally trivial. Famous last words.\"\nFrom: Linus Torvalds \nDate: Fri, 22 Jan 2010 07:29:21 -0800\n"},{"id":"218412","messageId":"7vmwrk89mb.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"20130524171110.GB9448@inner.h.apk.li","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-24T19:23:56Z","receivedAt":"2013-05-24T19:23:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Krey writes:\n\n> On Thu, 23 May 2013 09:01:15 +0000, Junio C Hamano wrote:\n> ...\n>> Instead of having a nice \"these six commits marked as 'x' were done\n>> on a branch forked some time ago, to address only this one issue and\n>> to address it fully\" history that explains how these commits were\n>> related and these commits are the full solution to a single issue:\n>> \n>> x---x---x---x---x---x\n>> / \\\n>> ---o---o---o---o---o---o---M---o---o---...\n>> \n>> they end up with something like this, even with the \"flip the heads\n>> of a merge\" option, by pulling too often:\n>> \n>> x---x x---x---x x\n>> / \\ / \\ / \\\n>> ---o---o---M---o---o---M---M---o---o---...\n>\n> Wouldn't that be (you don't want to put your work back into master before\n> it's done) the following?\n>\n> x---x---M---x---x---M--x\n> / / / \\\n> ---o---o---M---o---o---M--o---M---o---o---...\n\nThat is what you would get if you \"pull from my upstream\" with the\ncurrent software.\n\nAnd that is what triggered this discussion thread in which some\npeople said that they do not want that shape of the history.\n\nAt the leftmost merge M you drew on the upper line (i.e. your\ntopic), the merge pulls in other's commits that are unrelated to\neach other as if it were a meaningful group of commits on a side\nbranch. They want to see the merge going other way around, pulling\nyour work done on a side branch, integrating into the mainline.\n\nThe second illustration you are commenting on were done to explain\nwhy such a \"when pulling from my upstream, I want the order of\nparents swapped, so that mainline appears as the first parent\" is\nnot solving the whole issue. The time series would go more like\nthis:\n\n(1) While you were working on two 'x's, others have worked to\n advance the mainline:\n\n x---x Your 'master'\n /\n ---o---o Mainline\n\n\n(2) You cannot push without losing others work, so you pull, but in\n order to avoid the \"others work on mixed on a single side\n branch\" issue, you use the fictional \"flip heads of a merge\"\n option, and push the result out. That becomes the tip of the\n mainline:\n\n x---x\n / \\\n ---o---o---M\n\n(3) Then you keep working to build more commits on top. \n\n x---x x---x---x\n / \\ /\n ---o---o---M\n\n(4) And others also keep working.\n\n x---x x---x---x\n / \\ /\n ---o---o---M---o---o\n"},{"id":"218414","messageId":"9C8FD0BE27314D72A629025EFFF58848@PhilipOakley","threadId":"33899","inReplyTo":"7vli74baym.fsf@alter.siamese.dyndns.org","subject":"Re: first parent, commit graph layout, and pull merge direction","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-05-24T20:47:19Z","receivedAt":"2013-05-24T20:47:19Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Friday, May 24, 2013 5:26 PM\n> Felipe Contreras writes:\n>\n>> ... but I don't see why something small like that\n>> wouldn't make sense:\n>>\n>> The pull was not fast-forward, please either merge or rebase.\n>\n> OK, I think I got what John was getting at and this single liner\n> message is a good summary of it.\n>\n> Instead of telling them \"you cannot push this thing without losing\n> history from the location you are pushing to; you need to become up\n> to date with respect to them before pushing\" upon seeing a non ff\n> push failure, we can tell them \"you cannot update your history to\n> what the place you get new changes from has without losing your\n> history; you need to integrate the two\".\n>\n> Initially I said limiting \"git pull\" to \"--ff-only\" by default did\n> not make sense, but when we view it that way, I now see how such a\n> default makes sense.\n>\n> In another subthread, John Szakmeister mentioned that the \"please\n> 'git pull' first\" message that a \"push\" gives when it stops due to\n> non-ff nudges the users in a wrong direction, because they often\n> take that 'git pull' too literally (e.g. 'pull --rebase' may be\n> necessary in their project, not 'git pull').\n>\n> The original message deliberately avoided mentioning 'git pull' for\n> that exact reason, but in mid 2010 we made it worse. The log of\n> that change says that it attempted to\n>\n> ... remains fuzzy to include \"git pull\", \"git pull --rebase\" and\n> others, but directs the user to the simplest solution in the\n> vast majority of cases.\n>\n> but this thread shows that it did not work; the simplest solution\n> was a wrong one. The message also may need to be rethought to\n> complement this direction being proposed for \"pull\".\n> --\n\nPerhaps offer \"git pull ....\", which suggests that the user should \nconsider what pull parameters to provide and if taken literally should \nbarf with the four dots.\n\nPhilip\n"},{"id":"222126","messageId":"7v4ncjs5az.fsf_-_@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"CA+55aFz2Uvq4vmyjJPao5tS-uuVvKm6mbP7Uz8sdq1VMxMGJCw@mail.gmail.com","subject":"[PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-27T19:48:52Z","receivedAt":"2013-06-27T19:48:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Because letting a trivial merge automatically handled by Git is so\neasy with \"git pull\", a person who is new to Git may not realize\nthat the project s/he is interacting with may prefer \"rebase\"\nworkflow. Add a safety valve to fail \"git pull\" that is not a\nfast-forward until/unless the user expressed her preference between\nthe two.\n\nThose who want the existing behaviour could just do\n\n git config --global pull.rebase false\n\nonce, and they'd not even notice.\n\n http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=225326\n\nfor a full discussion.\n\nThe fallout from this change to test suite is not very pretty, though.\n\nSigned-off-by: Junio C Hamano \n---\n\n * This is not a serious inclusion proposal yet, but to see if\n people are still interested in possibly helping new users.\n\n git-pull.sh | 36 +++++++++++++++++++++++++++++++++-\n t/annotate-tests.sh | 2 +-\n t/t4013-diff-various.sh | 2 ++\n t/t4200-rerere.sh | 2 ++\n t/t5500-fetch-pack.sh | 6 +++++-\n t/t5521-pull-options.sh | 2 ++\n t/t5524-pull-msg.sh | 2 +-\n t/t5700-clone-reference.sh | 4 ++--\n t/t6022-merge-rename.sh | 2 ++\n t/t6026-merge-attr.sh | 2 +-\n t/t6029-merge-subtree.sh | 1 +\n t/t6037-merge-ours-theirs.sh | 2 ++\n t/t9114-git-svn-dcommit-merge.sh | 2 +-\n t/t9400-git-cvsserver-server.sh | 2 +-\n t/t9500-gitweb-standalone-no-errors.sh | 2 +-\n 15 files changed, 59 insertions(+), 10 deletions(-)\n\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 638aabb..4a6a863 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -41,13 +41,21 @@ test -f \"$GIT_DIR/MERGE_HEAD\" && die_merge\n strategy_args= diffstat= no_commit= squash= no_ff= ff_only=\n log_arg= verbosity= progress= recurse_submodules= verify_signatures=\n merge_args= edit=\n+\n curr_branch=$(git symbolic-ref -q HEAD)\n curr_branch_short=\"${curr_branch#refs/heads/}\"\n+\n+# See if we are configured to rebase by default.\n+# The value $rebase is, throughout the main part of the code:\n+# (empty) - the user did not have any preference\n+# true - the user told us to integrate by rebasing\n+# flase - the user told us to integrate by merging\n rebase=$(git config --bool branch.$curr_branch_short.rebase)\n if test -z \"$rebase\"\n then\n \trebase=$(git config --bool pull.rebase)\n fi\n+\n dry_run=\n while :\n do\n@@ -113,7 +121,8 @@ do\n \t-r|--r|--re|--reb|--reba|--rebas|--rebase)\n \t\trebase=true\n \t\t;;\n-\t--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)\n+\t--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase|\\\n+\t-m|--m|--me|--mer|--merg|--merge)\n \t\trebase=false\n \t\t;;\n \t--recurse-submodules)\n@@ -219,6 +228,7 @@ test true = \"$rebase\" && {\n \t\tfi\n \tdone\n }\n+\n orig_head=$(git rev-parse -q --verify HEAD)\n git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok \"$@\" || exit 1\n test -z \"$dry_run\" || exit 0\n@@ -264,6 +274,30 @@ case \"$merge_head\" in\n \t\tdie \"$(gettext \"Cannot rebase onto multiple branches\")\"\n \tfi\n \t;;\n+*)\n+\t# integrating with a single other history\n+\tmerge_head=${merge_head% }\n+\tif test -z \"$rebase$no_ff$ff_only${squash#--no-squash}\" &&\n+\t\ttest -n \"$orig_head\" &&\n+\t\t! $(git merge-base --is-ancestor \"$orig_head\" \"$merge_head\")\n+\tthen\n+echo >&2 \"orig-head was $orig_head\"\n+echo >&2 \"merge-head is $merge_head\"\n+git show >&2 --oneline -s \"$orig_head\" \"$merge_head\"\n+\n+\t\tdie \"The pull does not fast-forward; please specify\n+if you want to merge or rebase.\n+\n+Use either\n+\n+ git pull --rebase\n+ git pull --merge\n+\n+You can also use 'git config pull.rebase true' (if you want --rebase) or\n+'git config pull.rebase false' (if you want --merge) to set this once for\n+this project and forget about it.\"\n+\tfi\n+\t;;\n esac\n \n if test -z \"$orig_head\"\ndiff --git a/t/annotate-tests.sh b/t/annotate-tests.sh\nindex c56a77d..af02c6d 100644\n--- a/t/annotate-tests.sh\n+++ b/t/annotate-tests.sh\n@@ -79,7 +79,7 @@ test_expect_success \\\n \n test_expect_success \\\n 'merge-setup part 3' \\\n- 'git pull . branch1'\n+ 'git pull --merge . branch1'\n \n test_expect_success \\\n 'Two lines blamed on A, one on B, two on B1, one on B2' \\\ndiff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\nindex e77c09c..1ee2198 100755\n--- a/t/t4013-diff-various.sh\n+++ b/t/t4013-diff-various.sh\n@@ -12,6 +12,8 @@ LF='\n \n test_expect_success setup '\n \n+\tgit config pull.rebase false &&\n+\n \tGIT_AUTHOR_DATE=\"2006-06-26 00:00:00 +0000\" &&\n \tGIT_COMMITTER_DATE=\"2006-06-26 00:00:00 +0000\" &&\n \texport GIT_AUTHOR_DATE GIT_COMMITTER_DATE &&\ndiff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh\nindex 7f6666f..0563357 100755\n--- a/t/t4200-rerere.sh\n+++ b/t/t4200-rerere.sh\n@@ -25,6 +25,8 @@ test_description='git rerere\n . ./test-lib.sh\n \n test_expect_success 'setup' '\n+\tgit config pull.rebase false &&\n+\n \tcat >a1 <<-\\EOF &&\n \tSome title\n \t==========\ndiff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh\nindex fd2598e..4be8877 100755\n--- a/t/t5500-fetch-pack.sh\n+++ b/t/t5500-fetch-pack.sh\n@@ -143,7 +143,11 @@ test_expect_success 'clone shallow depth 1 with fsck' '\n '\n \n test_expect_success 'clone shallow' '\n-\tgit clone --no-single-branch --depth 2 \"file://$(pwd)/.\" shallow\n+\tgit clone --no-single-branch --depth 2 \"file://$(pwd)/.\" shallow &&\n+\t(\n+\t\tcd shallow &&\n+\t\tgit config pull.rebase false\n+\t)\n '\n \n test_expect_success 'clone shallow depth count' '\ndiff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh\nindex 453aba5..d821fab 100755\n--- a/t/t5521-pull-options.sh\n+++ b/t/t5521-pull-options.sh\n@@ -91,6 +91,8 @@ test_expect_success 'git pull --force' '\n \t[branch \"master\"]\n \t\tremote = two\n \t\tmerge = refs/heads/master\n+\t[pull]\n+\t\trebase = false\n \tEOF\n \tgit pull two &&\n \ttest_commit A &&\ndiff --git a/t/t5524-pull-msg.sh b/t/t5524-pull-msg.sh\nindex 8cccecc..660714b 100755\n--- a/t/t5524-pull-msg.sh\n+++ b/t/t5524-pull-msg.sh\n@@ -25,7 +25,7 @@ test_expect_success setup '\n test_expect_success pull '\n (\n \tcd cloned &&\n-\tgit pull --log &&\n+\tgit pull --log --merge &&\n \tgit log -2 &&\n \tgit cat-file commit HEAD >result &&\n \tgrep Dollar result\ndiff --git a/t/t5700-clone-reference.sh b/t/t5700-clone-reference.sh\nindex 6537911..306badf 100755\n--- a/t/t5700-clone-reference.sh\n+++ b/t/t5700-clone-reference.sh\n@@ -94,7 +94,7 @@ cd \"$base_dir\"\n \n test_expect_success 'pulling changes from origin' \\\n 'cd C &&\n-git pull origin'\n+git pull --merge origin'\n \n cd \"$base_dir\"\n \n@@ -109,7 +109,7 @@ cd \"$base_dir\"\n \n test_expect_success 'pulling changes from origin' \\\n 'cd D &&\n-git pull origin'\n+git pull --merge origin'\n \n cd \"$base_dir\"\n \ndiff --git a/t/t6022-merge-rename.sh b/t/t6022-merge-rename.sh\nindex c680f78..e12d90b 100755\n--- a/t/t6022-merge-rename.sh\n+++ b/t/t6022-merge-rename.sh\n@@ -10,6 +10,8 @@ modify () {\n \n test_expect_success setup \\\n '\n+git config pull.rebase false &&\n+\n cat >A <<\\EOF &&\n a aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n b bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\ndiff --git a/t/t6026-merge-attr.sh b/t/t6026-merge-attr.sh\nindex 5e43997..5428f19 100755\n--- a/t/t6026-merge-attr.sh\n+++ b/t/t6026-merge-attr.sh\n@@ -172,7 +172,7 @@ test_expect_success 'up-to-date merge without common ancestor' '\n \ttest_tick &&\n \t(\n \t\tcd repo1 &&\n-\t\tgit pull ../repo2 master\n+\t\tgit pull --merge ../repo2 master\n \t)\n '\n \ndiff --git a/t/t6029-merge-subtree.sh b/t/t6029-merge-subtree.sh\nindex 73fc240..3ca29c4 100755\n--- a/t/t6029-merge-subtree.sh\n+++ b/t/t6029-merge-subtree.sh\n@@ -41,6 +41,7 @@ test_expect_success 'setup' '\n \tmkdir git &&\n \tcd git &&\n \tgit init &&\n+\tgit config pull.rebase false &&\n \techo git >git.c &&\n \to2=$(git hash-object git.c) &&\n \tgit add git.c &&\ndiff --git a/t/t6037-merge-ours-theirs.sh b/t/t6037-merge-ours-theirs.sh\nindex 3889eca..41bf060 100755\n--- a/t/t6037-merge-ours-theirs.sh\n+++ b/t/t6037-merge-ours-theirs.sh\n@@ -66,6 +66,8 @@ test_expect_success 'binary file with -Xours/-Xtheirs' '\n '\n \n test_expect_success 'pull passes -X to underlying merge' '\n+\tgit config pull.rebase false &&\n+\n \tgit reset --hard master && git pull -s recursive -Xours . side &&\n \tgit reset --hard master && git pull -s recursive -X ours . side &&\n \tgit reset --hard master && git pull -s recursive -Xtheirs . side &&\ndiff --git a/t/t9114-git-svn-dcommit-merge.sh b/t/t9114-git-svn-dcommit-merge.sh\nindex f524d2f..dfce024 100755\n--- a/t/t9114-git-svn-dcommit-merge.sh\n+++ b/t/t9114-git-svn-dcommit-merge.sh\n@@ -62,7 +62,7 @@ test_expect_success 'setup git mirror and merge' '\n \techo friend > README &&\n \tcat tmp >> README &&\n \tgit commit -a -m \"friend\" &&\n-\tgit pull . merge\n+\tgit pull --merge . merge\n \t'\n \n test_debug 'gitk --all & sleep 1'\ndiff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh\nindex 0431386..76b8640 100755\n--- a/t/t9400-git-cvsserver-server.sh\n+++ b/t/t9400-git-cvsserver-server.sh\n@@ -46,7 +46,7 @@ test_expect_success 'setup' '\n touch secondrootfile &&\n git add secondrootfile &&\n git commit -m \"second root\") &&\n- git pull secondroot master &&\n+ git pull --merge secondroot master &&\n git clone -q --bare \"$WORKDIR/.git\" \"$SERVERDIR\" >/dev/null 2>&1 &&\n GIT_DIR=\"$SERVERDIR\" git config --bool gitcvs.enabled true &&\n GIT_DIR=\"$SERVERDIR\" git config gitcvs.logfile \"$SERVERDIR/gitcvs.log\" &&\ndiff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh\nindex 6fca193..787c6cc 100755\n--- a/t/t9500-gitweb-standalone-no-errors.sh\n+++ b/t/t9500-gitweb-standalone-no-errors.sh\n@@ -328,7 +328,7 @@ test_expect_success \\\n \t git add b &&\n \t git commit -a -m \"On branch\" &&\n \t git checkout master &&\n-\t git pull . b &&\n+\t git pull --merge . b &&\n \t git tag merge_commit'\n \n test_expect_success \\\n-- \n1.8.3.1-794-ga13ccd6\n"},{"id":"222136","messageId":"20130627201032.GF9999@odin.tremily.us","threadId":"33899","inReplyTo":"7v4ncjs5az.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2013-06-27T20:10:32Z","receivedAt":"2013-06-27T20:10:32Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:\n> Because letting a trivial merge automatically handled by Git is so\n> easy with \"git pull\", a person who is new to Git may not realize\n> that the project s/he is interacting with may prefer \"rebase\"\n> workflow.\n\nOr they may not even realize that they've just merged an unrelated\nbranch at all, dragging in a thousand unrelated commits which they\naccidentally push to a central repository without looking,\ncontaminating future branches based on the central repostitory without\ndrastic rebase surgery ;). I just saw one of these earlier this week.\n\n> * This is not a serious inclusion proposal yet, but to see if\n> people are still interested in possibly helping new users.\n\nWhat needs to happen to make it serious? I'm happy to help.\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":"222129","messageId":"20130627201142.GC27497@paksenarrion.iveqy.com","threadId":"33899","inReplyTo":"7v4ncjs5az.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2013-06-27T20:11:42Z","receivedAt":"2013-06-27T20:11:42Z","isPatch":true,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:\n\n> +# See if we are configured to rebase by default.\n> +# The value $rebase is, throughout the main part of the code:\n> +# (empty) - the user did not have any preference\n> +# true - the user told us to integrate by rebasing\n> +# flase - the user told us to integrate by merging\n\ns/flase/false\n\nAnd isn't all config settings documented somewhere?\n\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\ntel: 0733-608274\ne-post: iveqy@iveqy.com\n"},{"id":"222130","messageId":"20130627203007.GG9999@odin.tremily.us","threadId":"33899","inReplyTo":"7v4ncjs5az.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2013-06-27T20:30:07Z","receivedAt":"2013-06-27T20:30:07Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"Assorted minor edits:\n\nOn Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:\n> Because letting a trivial merge automatically handled by Git is so\n\nMaybe:\n\n Because letting Git handle a trivial merge automatically is so…\n\n> that the project s/he is interacting with may prefer \"rebase\"\n> workflow. Add a safety valve to fail \"git pull\" that is not a\n\nMaybe (adding an \"a\"):\n\n a \"rebase\" workflow.\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":"222131","messageId":"7vzjubqnx5.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"20130627201142.GC27497@paksenarrion.iveqy.com","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-27T20:49:42Z","receivedAt":"2013-06-27T20:49:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fredrik Gustafsson writes:\n\n> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:\n> \n>> +# See if we are configured to rebase by default.\n>> +# The value $rebase is, throughout the main part of the code:\n>> +# (empty) - the user did not have any preference\n>> +# true - the user told us to integrate by rebasing\n>> +# flase - the user told us to integrate by merging\n>\n> s/flase/false\n\nThanks.\n\n> And isn't all config settings documented somewhere?\n\nYes, but the above does not have anything to do with it. It is how\nthe variable in this script gets used---it may come from the config,\nbut it will be overridden by command line option.\n\nIf you do \"git config pull.rebase false\", it is an explicit show of\npreference to do \"pull --merge\".\n\nIf you do not have any pull.rebase in your configuration, *and* if\nyour command line does not say \"pull --merge\" nor \"pull --rebase\",\nthen $rebase will be empty, and that is how we detect that you\nhaven't given us any explicit preference (yet) and fail the command.\n"},{"id":"222134","messageId":"7vmwqbqnil.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"20130627203007.GG9999@odin.tremily.us","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-27T20:58:26Z","receivedAt":"2013-06-27T20:58:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"W. Trevor King\" writes:\n\n> Assorted minor edits:\n>\n> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:\n>> Because letting a trivial merge automatically handled by Git is so\n>\n> Maybe:\n>\n> Because letting Git handle a trivial merge automatically is so…\n>\n>> that the project s/he is interacting with may prefer \"rebase\"\n>> workflow. Add a safety valve to fail \"git pull\" that is not a\n>\n> Maybe (adding an \"a\"):\n>\n> a \"rebase\" workflow.\n\nThanks.\n"},{"id":"222137","messageId":"7vehbnqmhh.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"20130627201032.GF9999@odin.tremily.us","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-27T21:20:42Z","receivedAt":"2013-06-27T21:20:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"W. Trevor King\" writes:\n\n> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:\n>> Because letting a trivial merge automatically handled by Git is so\n>> easy with \"git pull\", a person who is new to Git may not realize\n>> that the project s/he is interacting with may prefer \"rebase\"\n>> workflow.\n>\n> Or they may not even realize that they've just merged an unrelated\n> branch at all, dragging in a thousand unrelated commits which they\n> accidentally push to a central repository without looking,\n> contaminating future branches based on the central repostitory without\n> drastic rebase surgery ;). I just saw one of these earlier this week.\n\nI am not sure \"running pull and integrate other's work in random\nbranches\" is something the proposed (not by me) change would help to\nprevent from happening.\n\nYour \"accident user\" could have just been on a 'maint' branch,\npulled the 'master' branch which would fast-forward and then pushed\nthe result back to 'maint', contaminating the shared 'maint' branch\nwith commits that do not match the purpose of it, which is to hold\nonly fixes without enhancements.\n"},{"id":"222138","messageId":"vpqwqpf9p2i.fsf@anie.imag.fr","threadId":"33899","inReplyTo":"7v4ncjs5az.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-06-27T22:16:53Z","receivedAt":"2013-06-27T22:16:53Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Because letting a trivial merge automatically handled by Git is so\n> easy with \"git pull\", a person who is new to Git may not realize\n> that the project s/he is interacting with may prefer \"rebase\"\n> workflow. Add a safety valve to fail \"git pull\" that is not a\n> fast-forward until/unless the user expressed her preference between\n> the two.\n\nIMHO, that would be terrible for beginners.\n\nMy experience with many beginners/students is: they run \"git pull\" to\nget changes from their co-workers, don't read the messages. When there's\nno conflict, it's OK, Git creates the merge commit and they continue\nworking. When there are conflicts, they fix it (or not), and forget to\ncommit, continue working, and commit when they really need to, later.\nThat's bad: mixing merges with actual changes is terrible. But that\nworks. And that's a very common mistake in my experience :-(.\n\nNow, give the same user as above \"git pull --rebase\". rebase may stop\nbecause of conflicts, the user may fix it, but then if the user\ncontinues working, he's on a detached HEAD with a rebase ongoing. Some\nof the changes went away, they may come back one day if the user runs\n\"git rebase --continue\".\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"222145","messageId":"20130628010839.GC11985@odin.tremily.us","threadId":"33899","inReplyTo":"7vehbnqmhh.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2013-06-28T01:08:39Z","receivedAt":"2013-06-28T01:08:39Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Thu, Jun 27, 2013 at 02:20:42PM -0700, Junio C Hamano wrote:\n> Your \"accident user\" could have just been on a 'maint' branch,\n> [snip]\n\nBy the time I talk people into using a 'maint' branch, we'll probably\nhave already passed the 'accidental pull and push' stage ;). This\nwill certainly reduce the risk in any case.\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":"222146","messageId":"20130628011902.GD11985@odin.tremily.us","threadId":"33899","inReplyTo":"vpqwqpf9p2i.fsf@anie.imag.fr","subject":"Re: Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2013-06-28T01:19:02Z","receivedAt":"2013-06-28T01:19:02Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, Jun 28, 2013 at 12:16:53AM +0200, Matthieu Moy wrote:\n> IMHO, that would be terrible for beginners.\n> \n> My experience with many beginners/students is: they run \"git pull\" to\n> get changes from their co-workers, don't read the messages.\n\nI admit that I'd be happy with a config option that just disabled pull\nentirely (forcing people to fetch/merge explicitly) to avoid this type\nof beginner mistake. With an unconfigured pull.rebase, this patch\ndoes that for merge/rebase cases, while still letting folks pull when\nit's a clean fast forward (usually ok).\n\nI'd also be happy with an opt-in disable. The real solution would be\nto talk my group out of using a central shared repository or into\nusing pull-free feature branches, but I don't see either on my\nhorizon. Git doesn't need to change to mitigate sloppy-shared-repo\nproblems, but having some sort of anti-pull configuration option would\ncertainly help me out.\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":"222152","messageId":"vpq1u7magky.fsf@anie.imag.fr","threadId":"33899","inReplyTo":"20130627201032.GF9999@odin.tremily.us","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-06-28T06:34:53Z","receivedAt":"2013-06-28T06:34:53Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"\"W. Trevor King\" writes:\n\n> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:\n>> Because letting a trivial merge automatically handled by Git is so\n>> easy with \"git pull\", a person who is new to Git may not realize\n>> that the project s/he is interacting with may prefer \"rebase\"\n>> workflow.\n>\n> Or they may not even realize that they've just merged an unrelated\n> branch at all, dragging in a thousand unrelated commits which they\n> accidentally push to a central repository without looking,\n> contaminating future branches based on the central repostitory without\n> drastic rebase surgery ;). I just saw one of these earlier this week.\n\nI don't understand how the change would solve this. If \"pull\" would drag\na lot of commits in the current branch, the \"rebase\" will rebase the\ncurrent branch on a totally different history, and pushing the result\nwould be equally bad.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"222155","messageId":"20130628080953.GD2232@serenity.lan","threadId":"33899","inReplyTo":"7v4ncjs5az.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-06-28T08:09:53Z","receivedAt":"2013-06-28T08:09:53Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:\n> Because letting a trivial merge automatically handled by Git is so\n> easy with \"git pull\", a person who is new to Git may not realize\n> that the project s/he is interacting with may prefer \"rebase\"\n> workflow. Add a safety valve to fail \"git pull\" that is not a\n> fast-forward until/unless the user expressed her preference between\n> the two.\n> \n> Those who want the existing behaviour could just do\n> \n> git config --global pull.rebase false\n> \n> once, and they'd not even notice.\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=225326\n> \n> for a full discussion.\n> \n> The fallout from this change to test suite is not very pretty, though.\n> \n> Signed-off-by: Junio C Hamano \n> ---\n[snip]\n> diff --git a/t/annotate-tests.sh b/t/annotate-tests.sh\n> index c56a77d..af02c6d 100644\n> --- a/t/annotate-tests.sh\n> +++ b/t/annotate-tests.sh\n> @@ -79,7 +79,7 @@ test_expect_success \\\n> \n> test_expect_success \\\n> 'merge-setup part 3' \\\n> - 'git pull . branch1'\n> + 'git pull --merge . branch1'\n\nI think the \"--merge\" should be implied here because the suer has\nspecified an explicit remote and branch. Similarly, if \"--ff\",\n\"--no-ff\" or \"--ff-only\" are given then we can infer \"--merge\" in the\nabsence of any other configuration.\n\nHowever, when I looked at doing this I decided that it would be\ndifficult to get that ideal behaviour without rewriting git-pull as a\nbuiltin.\n"},{"id":"222157","messageId":"20130628090917.GG11985@odin.tremily.us","threadId":"33899","inReplyTo":"vpq1u7magky.fsf@anie.imag.fr","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2013-06-28T09:09:17Z","receivedAt":"2013-06-28T09:09:17Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, Jun 28, 2013 at 08:34:53AM +0200, Matthieu Moy wrote:\n> \"W. Trevor King\" writes:\n> > On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:\n> >> Because letting a trivial merge automatically handled by Git is so\n> >> easy with \"git pull\", a person who is new to Git may not realize\n> >> that the project s/he is interacting with may prefer \"rebase\"\n> >> workflow.\n> >\n> > Or they may not even realize that they've just merged an unrelated\n> > branch at all, dragging in a thousand unrelated commits which they\n> > accidentally push to a central repository without looking,\n> > contaminating future branches based on the central repostitory without\n> > drastic rebase surgery ;). I just saw one of these earlier this week.\n> \n> I don't understand how the change would solve this. If \"pull\" would drag\n> a lot of commits in the current branch, the \"rebase\" will rebase the\n> current branch on a totally different history, and pushing the result\n> would be equally bad.\n\nI want the warning that they had not made the required config choice\nbetween rebase/merge needed to handle a non-ff case, not the default\nmerge (or rebase) behavior. The warning gives them a chance to\nrealize that this was not an appropriate time for a `svn update`\nanalog, and that the project may not to want to have the branches\njoined at all ;).\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":"222165","messageId":"vpqmwqa8nax.fsf@anie.imag.fr","threadId":"33899","inReplyTo":"20130628090917.GG11985@odin.tremily.us","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-06-28T11:52:38Z","receivedAt":"2013-06-28T11:52:38Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"\"W. Trevor King\" writes:\n\n> On Fri, Jun 28, 2013 at 08:34:53AM +0200, Matthieu Moy wrote:\n>> \"W. Trevor King\" writes:\n>>\n>> > Or they may not even realize that they've just merged an unrelated\n>> > branch at all, dragging in a thousand unrelated commits which they\n>> > accidentally push to a central repository without looking,\n>> > contaminating future branches based on the central repostitory without\n>> > drastic rebase surgery ;). I just saw one of these earlier this week.\n>> \n>> I don't understand how the change would solve this. If \"pull\" would drag\n>> a lot of commits in the current branch, the \"rebase\" will rebase the\n>> current branch on a totally different history, and pushing the result\n>> would be equally bad.\n>\n> I want the warning that they had not made the required config choice\n> between rebase/merge needed to handle a non-ff case, not the default\n> merge (or rebase) behavior. The warning gives them a chance to\n> realize that this was not an appropriate time for a `svn update`\n> analog, and that the project may not to want to have the branches\n> joined at all ;).\n\nYou're assuming that the config is not made, but this is supposed to\nhappen once initially. Then, the user will chose either merge or rebase,\nand whatever is chosen, the result will be bad.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"222173","messageId":"20130628122834.GH11985@odin.tremily.us","threadId":"33899","inReplyTo":"vpqmwqa8nax.fsf@anie.imag.fr","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"W. Trevor King","fromEmail":"wking@tremily.us","sentAt":"2013-06-28T12:28:34Z","receivedAt":"2013-06-28T12:28:34Z","isPatch":true,"sender":{"key":"wking@tremily.us","avatar":"https://avatars.githubusercontent.com/u/209920?v=4"},"body":"On Fri, Jun 28, 2013 at 01:52:38PM +0200, Matthieu Moy wrote:\n> \"W. Trevor King\" writes:\n> > I want the warning that they had not made the required config choice\n> > between rebase/merge needed to handle a non-ff case, not the default\n> > merge (or rebase) behavior. The warning gives them a chance to\n> > realize that this was not an appropriate time for a `svn update`\n> > analog, and that the project may not to want to have the branches\n> > joined at all ;).\n> \n> You're assuming that the config is not made, but this is supposed to\n> happen once initially. Then, the user will chose either merge or rebase,\n> and whatever is chosen, the result will be bad.\n\nI'm hoping that reading the error message reminds them that these\ncross-branch pulls are not recommended (for us), and that they skip\nthe configuration step (so they'll get the same warning after their\nnext subconcious pull). Of course, there are no guarantees. But if\nthey do configure their rebase/merge preference and make and push bad\nmerge, at least I'll have something I can suggest as a finger-breaker.\n\nOf course, they should already be seeing their editor with a merge\ncommit message that they are ok-ing. If that's not enough to make\nthem think twice, a warning that:\n\n The pull does not fast-forward; …\n\nmay fall on deaf ears (blind eyes?). However, for folks used to only\nhaving a single branch, this may be enough of a jolt to wake them up.\n\nI'm not making a very strong case, and this whole line of reasoning is\ngetting off topic for this PR. Unless we adapt it to:\n\n pull.non-ff = {merge,rebase,never}\n\nwhich is, I think, even less likely to land ;).\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":"222194","messageId":"7vli5up2tq.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"20130628080953.GD2232@serenity.lan","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-28T17:22:57Z","receivedAt":"2013-06-28T17:22:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping writes:\n\n>> test_expect_success \\\n>> 'merge-setup part 3' \\\n>> - 'git pull . branch1'\n>> + 'git pull --merge . branch1'\n>\n> I think the \"--merge\" should be implied here because the suer has\n> specified an explicit remote and branch.\n\nThe whole point of the topic is \"It used to be that when you said\n'git pull' and did not tell us your preferred way to integrate your\nwork and work by the others', we default to merging, but we no\nlonger do so---you have to choose.\"\n\nHere, \"git pull . branch1\" is merely saying \"I want to integrate\nthe work on my current branch with that of branch1\" without saying\nhow that integration wants to happen.\n\nEven though, as an old timer, I find it mildly irritating that we\nnow have to be explicit in these tests, this change is in line with\nthe spirit of the topic. If we didn't have to change this example\nand the pull silently succeeded without complaining, we achieved\nnothing.\n\n> Similarly, if \"--ff\",\n> \"--no-ff\" or \"--ff-only\" are given then we can infer \"--merge\" in the\n> absence of any other configuration.\n\nIsn't that already there in the patch to git-merge?\n"},{"id":"222197","messageId":"20130628174252.GF2232@serenity.lan","threadId":"33899","inReplyTo":"7vli5up2tq.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-06-28T17:42:53Z","receivedAt":"2013-06-28T17:42:53Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Fri, Jun 28, 2013 at 10:22:57AM -0700, Junio C Hamano wrote:\n> John Keeping writes:\n> \n> >> test_expect_success \\\n> >> 'merge-setup part 3' \\\n> >> - 'git pull . branch1'\n> >> + 'git pull --merge . branch1'\n> >\n> > I think the \"--merge\" should be implied here because the suer has\n> > specified an explicit remote and branch.\n> \n> The whole point of the topic is \"It used to be that when you said\n> 'git pull' and did not tell us your preferred way to integrate your\n> work and work by the others', we default to merging, but we no\n> longer do so---you have to choose.\"\n> \n> Here, \"git pull . branch1\" is merely saying \"I want to integrate\n> the work on my current branch with that of branch1\" without saying\n> how that integration wants to happen.\n\nThe change that I think is important is that the \"bring my branch\nup-to-date\" operation should force the user to choose what to do if the\nbranch does not fast-forward to its upstream. If that was spelled \"git\nupdate\" then having \"git pull\" perform a merge would be fine, but we\nspell this operation as \"git pull\" so the change needs to happen there.\n\nI don't think \"git pull remote branch\" falls into the same category as\nplain \"git pull\" so I'm not convinced that defaulting to merge there is\nunreasonable. The original message about this [1] did talk about only\n\"git pull\" with no arguments.\n\n> Even though, as an old timer, I find it mildly irritating that we\n> now have to be explicit in these tests, this change is in line with\n> the spirit of the topic. If we didn't have to change this example\n> and the pull silently succeeded without complaining, we achieved\n> nothing.\n\nI disagree that we would have achieved nothing. New users will not be\nusing explicit arguments to git-pull when just trying to bring a branch\nup-to-date.\n\n[1] http://article.gmane.org/gmane.comp.version-control.git/225240\n"},{"id":"222222","messageId":"7vvc4xluxt.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"20130628174252.GF2232@serenity.lan","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-06-28T22:41:34Z","receivedAt":"2013-06-28T22:41:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping writes:\n\n>> Here, \"git pull . branch1\" is merely saying \"I want to integrate\n>> the work on my current branch with that of branch1\" without saying\n>> how that integration wants to happen.\n>\n> The change that I think is important is that the \"bring my branch\n> up-to-date\" operation should force the user to choose what to do if the\n> branch does not fast-forward to its upstream. If that was spelled \"git\n> update\" then having \"git pull\" perform a merge would be fine, but we\n> spell this operation as \"git pull\" so the change needs to happen there.\n\nI am not sure I quite get what you want to say with \"git update\",\nand I am not sure if I necessarily want to know---I do not think we\nwould want to add yet another command that DWIMs for certain _I_,\nthat may not match newbie expectations.\n\n> I don't think \"git pull remote branch\" falls into the same category as\n> plain \"git pull\" so I'm not convinced that defaulting to merge there is\n> unreasonable. The original message about this [1] did talk about only\n> \"git pull\" with no arguments.\n\nIf you want to limit the scope to only \"git pull\" (without any\ncommand line argument), I actually do not have strong preference for\nor against it either way. Perhaps a follow-up patch to be squashed?\n"},{"id":"222405","messageId":"20130702211820.GD9161@serenity.lan","threadId":"33899","inReplyTo":"7vvc4xluxt.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-07-02T21:18:20Z","receivedAt":"2013-07-02T21:18:20Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Fri, Jun 28, 2013 at 03:41:34PM -0700, Junio C Hamano wrote:\n> John Keeping writes:\n> \n> >> Here, \"git pull . branch1\" is merely saying \"I want to integrate\n> >> the work on my current branch with that of branch1\" without saying\n> >> how that integration wants to happen.\n> >\n> > The change that I think is important is that the \"bring my branch\n> > up-to-date\" operation should force the user to choose what to do if the\n> > branch does not fast-forward to its upstream. If that was spelled \"git\n> > update\" then having \"git pull\" perform a merge would be fine, but we\n> > spell this operation as \"git pull\" so the change needs to happen there.\n> \n> I am not sure I quite get what you want to say with \"git update\",\n> and I am not sure if I necessarily want to know---I do not think we\n> would want to add yet another command that DWIMs for certain _I_,\n> that may not match newbie expectations.\n\nI wasn't proposing any new command, I was trying to express the\noperation that users coming from non-distributed VCSs want to perform\n(which is called \"update\" in svn). The problem is that a DVCS operates\nin a completely different way and a lot of users do not seem to want to\nlearn the difference but simply try to map the existing commands that\nthey know onto Git commands ([1] is the top result for \"svn commands to\ngit\" on Google and maps \"svn update\" straight to \"git pull\").\n\n[1] http://git.or.cz/course/svn.html\n\n> > I don't think \"git pull remote branch\" falls into the same category as\n> > plain \"git pull\" so I'm not convinced that defaulting to merge there is\n> > unreasonable. The original message about this [1] did talk about only\n> > \"git pull\" with no arguments.\n> \n> If you want to limit the scope to only \"git pull\" (without any\n> command line argument), I actually do not have strong preference for\n> or against it either way. Perhaps a follow-up patch to be squashed?\n\nI remember looking at this a few weeks ago and being concerned that it's\nimpossible to tell what options you actually have in git-pull because it\njust invokes 'git fetch \"$@\"' and git-pull(1) does advertise a number of\nfetch options. It may be that \"test $# = 0\" is good enough, but ideally\nI want to test for non-option arguments.\n\nI can't see a way of doing this without putting knowledge of all of the\nfetch options in git-pull so that we can handle options with arguments\ncorrectly.\n"},{"id":"223326","messageId":"20130714150318.GB2239@serenity.lan","threadId":"33899","inReplyTo":"7vvc4xluxt.fsf@alter.siamese.dyndns.org","subject":"[PATCH] fixup! pull: require choice between rebase/merge on non-fast-forward pull","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-07-14T15:03:18Z","receivedAt":"2013-07-14T15:03:18Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"---\nOn Fri, Jun 28, 2013 at 03:41:34PM -0700, Junio C Hamano wrote:\n> John Keeping writes:\n> > I don't think \"git pull remote branch\" falls into the same category as\n> > plain \"git pull\" so I'm not convinced that defaulting to merge there is\n> > unreasonable. The original message about this [1] did talk about only\n> > \"git pull\" with no arguments.\n> \n> If you want to limit the scope to only \"git pull\" (without any\n> command line argument), I actually do not have strong preference for\n> or against it either way. Perhaps a follow-up patch to be squashed?\n\nHere is that patch. The test changes here are all reverting changes in\nae2dab2 (pull: require choice between rebase/merge on non-fast-forward\npull, 2013-06-27) - with this change to git-pull.sh the only change\nneeded in the tests is in t5524-pull-msg:\n\n $ git diff ae2dab2^ -- t\n diff --git a/t/t5524-pull-msg.sh b/t/t5524-pull-msg.sh\n index 8cccecc..660714b 100755\n --- a/t/t5524-pull-msg.sh\n +++ b/t/t5524-pull-msg.sh\n @@ -25,7 +25,7 @@ test_expect_success setup '\n test_expect_success pull '\n (\n cd cloned &&\n - git pull --log &&\n + git pull --log --merge &&\n git log -2 &&\n git cat-file commit HEAD >result &&\n grep Dollar result\n\n git-pull.sh | 1 +\n t/annotate-tests.sh | 2 +-\n t/t4013-diff-various.sh | 2 --\n t/t4200-rerere.sh | 2 --\n t/t5500-fetch-pack.sh | 6 +-----\n t/t5521-pull-options.sh | 2 --\n t/t5700-clone-reference.sh | 4 ++--\n t/t6022-merge-rename.sh | 2 --\n t/t6026-merge-attr.sh | 2 +-\n t/t6029-merge-subtree.sh | 1 -\n t/t6037-merge-ours-theirs.sh | 2 --\n t/t9114-git-svn-dcommit-merge.sh | 2 +-\n t/t9400-git-cvsserver-server.sh | 2 +-\n t/t9500-gitweb-standalone-no-errors.sh | 2 +-\n 14 files changed, 9 insertions(+), 23 deletions(-)\n\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 5ce67f9..0ff4a98 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -279,6 +279,7 @@ case \"$merge_head\" in\n \tmerge_head=${merge_head% }\n \tif test -z \"$rebase$no_ff$ff_only${squash#--no-squash}\" &&\n \t\ttest -n \"$orig_head\" &&\n+\t\ttest $# = 0 &&\n \t\t! $(git merge-base --is-ancestor \"$orig_head\" \"$merge_head\")\n \tthen\n echo >&2 \"orig-head was $orig_head\"\ndiff --git a/t/annotate-tests.sh b/t/annotate-tests.sh\nindex af02c6d..c56a77d 100644\n--- a/t/annotate-tests.sh\n+++ b/t/annotate-tests.sh\n@@ -79,7 +79,7 @@ test_expect_success \\\n \n test_expect_success \\\n 'merge-setup part 3' \\\n- 'git pull --merge . branch1'\n+ 'git pull . branch1'\n \n test_expect_success \\\n 'Two lines blamed on A, one on B, two on B1, one on B2' \\\ndiff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\nindex 1ee2198..e77c09c 100755\n--- a/t/t4013-diff-various.sh\n+++ b/t/t4013-diff-various.sh\n@@ -12,8 +12,6 @@ LF='\n \n test_expect_success setup '\n \n-\tgit config pull.rebase false &&\n-\n \tGIT_AUTHOR_DATE=\"2006-06-26 00:00:00 +0000\" &&\n \tGIT_COMMITTER_DATE=\"2006-06-26 00:00:00 +0000\" &&\n \texport GIT_AUTHOR_DATE GIT_COMMITTER_DATE &&\ndiff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh\nindex 0563357..7f6666f 100755\n--- a/t/t4200-rerere.sh\n+++ b/t/t4200-rerere.sh\n@@ -25,8 +25,6 @@ test_description='git rerere\n . ./test-lib.sh\n \n test_expect_success 'setup' '\n-\tgit config pull.rebase false &&\n-\n \tcat >a1 <<-\\EOF &&\n \tSome title\n \t==========\ndiff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh\nindex 4be8877..fd2598e 100755\n--- a/t/t5500-fetch-pack.sh\n+++ b/t/t5500-fetch-pack.sh\n@@ -143,11 +143,7 @@ test_expect_success 'clone shallow depth 1 with fsck' '\n '\n \n test_expect_success 'clone shallow' '\n-\tgit clone --no-single-branch --depth 2 \"file://$(pwd)/.\" shallow &&\n-\t(\n-\t\tcd shallow &&\n-\t\tgit config pull.rebase false\n-\t)\n+\tgit clone --no-single-branch --depth 2 \"file://$(pwd)/.\" shallow\n '\n \n test_expect_success 'clone shallow depth count' '\ndiff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh\nindex d821fab..453aba5 100755\n--- a/t/t5521-pull-options.sh\n+++ b/t/t5521-pull-options.sh\n@@ -91,8 +91,6 @@ test_expect_success 'git pull --force' '\n \t[branch \"master\"]\n \t\tremote = two\n \t\tmerge = refs/heads/master\n-\t[pull]\n-\t\trebase = false\n \tEOF\n \tgit pull two &&\n \ttest_commit A &&\ndiff --git a/t/t5700-clone-reference.sh b/t/t5700-clone-reference.sh\nindex 306badf..6537911 100755\n--- a/t/t5700-clone-reference.sh\n+++ b/t/t5700-clone-reference.sh\n@@ -94,7 +94,7 @@ cd \"$base_dir\"\n \n test_expect_success 'pulling changes from origin' \\\n 'cd C &&\n-git pull --merge origin'\n+git pull origin'\n \n cd \"$base_dir\"\n \n@@ -109,7 +109,7 @@ cd \"$base_dir\"\n \n test_expect_success 'pulling changes from origin' \\\n 'cd D &&\n-git pull --merge origin'\n+git pull origin'\n \n cd \"$base_dir\"\n \ndiff --git a/t/t6022-merge-rename.sh b/t/t6022-merge-rename.sh\nindex e12d90b..c680f78 100755\n--- a/t/t6022-merge-rename.sh\n+++ b/t/t6022-merge-rename.sh\n@@ -10,8 +10,6 @@ modify () {\n \n test_expect_success setup \\\n '\n-git config pull.rebase false &&\n-\n cat >A <<\\EOF &&\n a aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n b bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\ndiff --git a/t/t6026-merge-attr.sh b/t/t6026-merge-attr.sh\nindex 5428f19..5e43997 100755\n--- a/t/t6026-merge-attr.sh\n+++ b/t/t6026-merge-attr.sh\n@@ -172,7 +172,7 @@ test_expect_success 'up-to-date merge without common ancestor' '\n \ttest_tick &&\n \t(\n \t\tcd repo1 &&\n-\t\tgit pull --merge ../repo2 master\n+\t\tgit pull ../repo2 master\n \t)\n '\n \ndiff --git a/t/t6029-merge-subtree.sh b/t/t6029-merge-subtree.sh\nindex 3ca29c4..73fc240 100755\n--- a/t/t6029-merge-subtree.sh\n+++ b/t/t6029-merge-subtree.sh\n@@ -41,7 +41,6 @@ test_expect_success 'setup' '\n \tmkdir git &&\n \tcd git &&\n \tgit init &&\n-\tgit config pull.rebase false &&\n \techo git >git.c &&\n \to2=$(git hash-object git.c) &&\n \tgit add git.c &&\ndiff --git a/t/t6037-merge-ours-theirs.sh b/t/t6037-merge-ours-theirs.sh\nindex 41bf060..3889eca 100755\n--- a/t/t6037-merge-ours-theirs.sh\n+++ b/t/t6037-merge-ours-theirs.sh\n@@ -66,8 +66,6 @@ test_expect_success 'binary file with -Xours/-Xtheirs' '\n '\n \n test_expect_success 'pull passes -X to underlying merge' '\n-\tgit config pull.rebase false &&\n-\n \tgit reset --hard master && git pull -s recursive -Xours . side &&\n \tgit reset --hard master && git pull -s recursive -X ours . side &&\n \tgit reset --hard master && git pull -s recursive -Xtheirs . side &&\ndiff --git a/t/t9114-git-svn-dcommit-merge.sh b/t/t9114-git-svn-dcommit-merge.sh\nindex dfce024..f524d2f 100755\n--- a/t/t9114-git-svn-dcommit-merge.sh\n+++ b/t/t9114-git-svn-dcommit-merge.sh\n@@ -62,7 +62,7 @@ test_expect_success 'setup git mirror and merge' '\n \techo friend > README &&\n \tcat tmp >> README &&\n \tgit commit -a -m \"friend\" &&\n-\tgit pull --merge . merge\n+\tgit pull . merge\n \t'\n \n test_debug 'gitk --all & sleep 1'\ndiff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh\nindex 76b8640..0431386 100755\n--- a/t/t9400-git-cvsserver-server.sh\n+++ b/t/t9400-git-cvsserver-server.sh\n@@ -46,7 +46,7 @@ test_expect_success 'setup' '\n touch secondrootfile &&\n git add secondrootfile &&\n git commit -m \"second root\") &&\n- git pull --merge secondroot master &&\n+ git pull secondroot master &&\n git clone -q --bare \"$WORKDIR/.git\" \"$SERVERDIR\" >/dev/null 2>&1 &&\n GIT_DIR=\"$SERVERDIR\" git config --bool gitcvs.enabled true &&\n GIT_DIR=\"$SERVERDIR\" git config gitcvs.logfile \"$SERVERDIR/gitcvs.log\" &&\ndiff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh\nindex 787c6cc..6fca193 100755\n--- a/t/t9500-gitweb-standalone-no-errors.sh\n+++ b/t/t9500-gitweb-standalone-no-errors.sh\n@@ -328,7 +328,7 @@ test_expect_success \\\n \t git add b &&\n \t git commit -a -m \"On branch\" &&\n \t git checkout master &&\n-\t git pull --merge . b &&\n+\t git pull . b &&\n \t git tag merge_commit'\n \n test_expect_success \\\n-- \n1.8.3.2.922.gc9d4734\n"},{"id":"223374","messageId":"7vr4f0e9jq.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"20130714150318.GB2239@serenity.lan","subject":"Re: [PATCH] fixup! pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-15T04:23:05Z","receivedAt":"2013-07-15T04:23:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping writes:\n\n> Here is that patch. The test changes here are all reverting changes in\n> ae2dab2 (pull: require choice between rebase/merge on non-fast-forward\n> pull, 2013-06-27) - with this change to git-pull.sh the only change\n> needed in the tests is in t5524-pull-msg:\n>\n> $ git diff ae2dab2^ -- t\n> diff --git a/t/t5524-pull-msg.sh b/t/t5524-pull-msg.sh\n> index 8cccecc..660714b 100755\n> --- a/t/t5524-pull-msg.sh\n> +++ b/t/t5524-pull-msg.sh\n> @@ -25,7 +25,7 @@ test_expect_success setup '\n> test_expect_success pull '\n> (\n> cd cloned &&\n> - git pull --log &&\n> + git pull --log --merge &&\n\nNice. \"--log\" is not a pass-thru option to \"fetch\" and here it does\nnot count as part of \"$@\", so we do require the user to say how the\nintegration should happen, between --merge and --rebase.\n\nThanks, will queue.\n\n> git log -2 &&\n> git cat-file commit HEAD >result &&\n> grep Dollar result\n>\n> git-pull.sh | 1 +\n> t/annotate-tests.sh | 2 +-\n> t/t4013-diff-various.sh | 2 --\n> t/t4200-rerere.sh | 2 --\n> t/t5500-fetch-pack.sh | 6 +-----\n> t/t5521-pull-options.sh | 2 --\n> t/t5700-clone-reference.sh | 4 ++--\n> t/t6022-merge-rename.sh | 2 --\n> t/t6026-merge-attr.sh | 2 +-\n> t/t6029-merge-subtree.sh | 1 -\n> t/t6037-merge-ours-theirs.sh | 2 --\n> t/t9114-git-svn-dcommit-merge.sh | 2 +-\n> t/t9400-git-cvsserver-server.sh | 2 +-\n> t/t9500-gitweb-standalone-no-errors.sh | 2 +-\n> 14 files changed, 9 insertions(+), 23 deletions(-)\n>\n> diff --git a/git-pull.sh b/git-pull.sh\n> index 5ce67f9..0ff4a98 100755\n> --- a/git-pull.sh\n> +++ b/git-pull.sh\n> @@ -279,6 +279,7 @@ case \"$merge_head\" in\n> \tmerge_head=${merge_head% }\n> \tif test -z \"$rebase$no_ff$ff_only${squash#--no-squash}\" &&\n> \t\ttest -n \"$orig_head\" &&\n> +\t\ttest $# = 0 &&\n> \t\t! $(git merge-base --is-ancestor \"$orig_head\" \"$merge_head\")\n> \tthen\n> echo >&2 \"orig-head was $orig_head\"\n> diff --git a/t/annotate-tests.sh b/t/annotate-tests.sh\n> index af02c6d..c56a77d 100644\n> --- a/t/annotate-tests.sh\n> +++ b/t/annotate-tests.sh\n> @@ -79,7 +79,7 @@ test_expect_success \\\n> \n> test_expect_success \\\n> 'merge-setup part 3' \\\n> - 'git pull --merge . branch1'\n> + 'git pull . branch1'\n> \n> test_expect_success \\\n> 'Two lines blamed on A, one on B, two on B1, one on B2' \\\n> diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh\n> index 1ee2198..e77c09c 100755\n> --- a/t/t4013-diff-various.sh\n> +++ b/t/t4013-diff-various.sh\n> @@ -12,8 +12,6 @@ LF='\n> \n> test_expect_success setup '\n> \n> -\tgit config pull.rebase false &&\n> -\n> \tGIT_AUTHOR_DATE=\"2006-06-26 00:00:00 +0000\" &&\n> \tGIT_COMMITTER_DATE=\"2006-06-26 00:00:00 +0000\" &&\n> \texport GIT_AUTHOR_DATE GIT_COMMITTER_DATE &&\n> diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh\n> index 0563357..7f6666f 100755\n> --- a/t/t4200-rerere.sh\n> +++ b/t/t4200-rerere.sh\n> @@ -25,8 +25,6 @@ test_description='git rerere\n> . ./test-lib.sh\n> \n> test_expect_success 'setup' '\n> -\tgit config pull.rebase false &&\n> -\n> \tcat >a1 <<-\\EOF &&\n> \tSome title\n> \t==========\n> diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh\n> index 4be8877..fd2598e 100755\n> --- a/t/t5500-fetch-pack.sh\n> +++ b/t/t5500-fetch-pack.sh\n> @@ -143,11 +143,7 @@ test_expect_success 'clone shallow depth 1 with fsck' '\n> '\n> \n> test_expect_success 'clone shallow' '\n> -\tgit clone --no-single-branch --depth 2 \"file://$(pwd)/.\" shallow &&\n> -\t(\n> -\t\tcd shallow &&\n> -\t\tgit config pull.rebase false\n> -\t)\n> +\tgit clone --no-single-branch --depth 2 \"file://$(pwd)/.\" shallow\n> '\n> \n> test_expect_success 'clone shallow depth count' '\n> diff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh\n> index d821fab..453aba5 100755\n> --- a/t/t5521-pull-options.sh\n> +++ b/t/t5521-pull-options.sh\n> @@ -91,8 +91,6 @@ test_expect_success 'git pull --force' '\n> \t[branch \"master\"]\n> \t\tremote = two\n> \t\tmerge = refs/heads/master\n> -\t[pull]\n> -\t\trebase = false\n> \tEOF\n> \tgit pull two &&\n> \ttest_commit A &&\n> diff --git a/t/t5700-clone-reference.sh b/t/t5700-clone-reference.sh\n> index 306badf..6537911 100755\n> --- a/t/t5700-clone-reference.sh\n> +++ b/t/t5700-clone-reference.sh\n> @@ -94,7 +94,7 @@ cd \"$base_dir\"\n> \n> test_expect_success 'pulling changes from origin' \\\n> 'cd C &&\n> -git pull --merge origin'\n> +git pull origin'\n> \n> cd \"$base_dir\"\n> \n> @@ -109,7 +109,7 @@ cd \"$base_dir\"\n> \n> test_expect_success 'pulling changes from origin' \\\n> 'cd D &&\n> -git pull --merge origin'\n> +git pull origin'\n> \n> cd \"$base_dir\"\n> \n> diff --git a/t/t6022-merge-rename.sh b/t/t6022-merge-rename.sh\n> index e12d90b..c680f78 100755\n> --- a/t/t6022-merge-rename.sh\n> +++ b/t/t6022-merge-rename.sh\n> @@ -10,8 +10,6 @@ modify () {\n> \n> test_expect_success setup \\\n> '\n> -git config pull.rebase false &&\n> -\n> cat >A <<\\EOF &&\n> a aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n> b bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\n> diff --git a/t/t6026-merge-attr.sh b/t/t6026-merge-attr.sh\n> index 5428f19..5e43997 100755\n> --- a/t/t6026-merge-attr.sh\n> +++ b/t/t6026-merge-attr.sh\n> @@ -172,7 +172,7 @@ test_expect_success 'up-to-date merge without common ancestor' '\n> \ttest_tick &&\n> \t(\n> \t\tcd repo1 &&\n> -\t\tgit pull --merge ../repo2 master\n> +\t\tgit pull ../repo2 master\n> \t)\n> '\n> \n> diff --git a/t/t6029-merge-subtree.sh b/t/t6029-merge-subtree.sh\n> index 3ca29c4..73fc240 100755\n> --- a/t/t6029-merge-subtree.sh\n> +++ b/t/t6029-merge-subtree.sh\n> @@ -41,7 +41,6 @@ test_expect_success 'setup' '\n> \tmkdir git &&\n> \tcd git &&\n> \tgit init &&\n> -\tgit config pull.rebase false &&\n> \techo git >git.c &&\n> \to2=$(git hash-object git.c) &&\n> \tgit add git.c &&\n> diff --git a/t/t6037-merge-ours-theirs.sh b/t/t6037-merge-ours-theirs.sh\n> index 41bf060..3889eca 100755\n> --- a/t/t6037-merge-ours-theirs.sh\n> +++ b/t/t6037-merge-ours-theirs.sh\n> @@ -66,8 +66,6 @@ test_expect_success 'binary file with -Xours/-Xtheirs' '\n> '\n> \n> test_expect_success 'pull passes -X to underlying merge' '\n> -\tgit config pull.rebase false &&\n> -\n> \tgit reset --hard master && git pull -s recursive -Xours . side &&\n> \tgit reset --hard master && git pull -s recursive -X ours . side &&\n> \tgit reset --hard master && git pull -s recursive -Xtheirs . side &&\n> diff --git a/t/t9114-git-svn-dcommit-merge.sh b/t/t9114-git-svn-dcommit-merge.sh\n> index dfce024..f524d2f 100755\n> --- a/t/t9114-git-svn-dcommit-merge.sh\n> +++ b/t/t9114-git-svn-dcommit-merge.sh\n> @@ -62,7 +62,7 @@ test_expect_success 'setup git mirror and merge' '\n> \techo friend > README &&\n> \tcat tmp >> README &&\n> \tgit commit -a -m \"friend\" &&\n> -\tgit pull --merge . merge\n> +\tgit pull . merge\n> \t'\n> \n> test_debug 'gitk --all & sleep 1'\n> diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh\n> index 76b8640..0431386 100755\n> --- a/t/t9400-git-cvsserver-server.sh\n> +++ b/t/t9400-git-cvsserver-server.sh\n> @@ -46,7 +46,7 @@ test_expect_success 'setup' '\n> touch secondrootfile &&\n> git add secondrootfile &&\n> git commit -m \"second root\") &&\n> - git pull --merge secondroot master &&\n> + git pull secondroot master &&\n> git clone -q --bare \"$WORKDIR/.git\" \"$SERVERDIR\" >/dev/null 2>&1 &&\n> GIT_DIR=\"$SERVERDIR\" git config --bool gitcvs.enabled true &&\n> GIT_DIR=\"$SERVERDIR\" git config gitcvs.logfile \"$SERVERDIR/gitcvs.log\" &&\n> diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh\n> index 787c6cc..6fca193 100755\n> --- a/t/t9500-gitweb-standalone-no-errors.sh\n> +++ b/t/t9500-gitweb-standalone-no-errors.sh\n> @@ -328,7 +328,7 @@ test_expect_success \\\n> \t git add b &&\n> \t git commit -a -m \"On branch\" &&\n> \t git checkout master &&\n> -\t git pull --merge . b &&\n> +\t git pull . b &&\n> \t git tag merge_commit'\n> \n> test_expect_success \\\n"},{"id":"223649","messageId":"20130718143009.GC2337@serenity.lan","threadId":"33899","inReplyTo":"7v4ncjs5az.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2013-07-18T14:30:09Z","receivedAt":"2013-07-18T14:30:09Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:\n> diff --git a/git-pull.sh b/git-pull.sh\n> index 638aabb..4a6a863 100755\n> --- a/git-pull.sh\n> +++ b/git-pull.sh\n> @@ -264,6 +274,30 @@ case \"$merge_head\" in\n> \t\tdie \"$(gettext \"Cannot rebase onto multiple branches\")\"\n> \tfi\n> \t;;\n> +*)\n> +\t# integrating with a single other history\n> +\tmerge_head=${merge_head% }\n> +\tif test -z \"$rebase$no_ff$ff_only${squash#--no-squash}\" &&\n> +\t\ttest -n \"$orig_head\" &&\n> +\t\t! $(git merge-base --is-ancestor \"$orig_head\" \"$merge_head\")\n\nI think this needs to be:\n\n\t! $(git merge-base --is-ancestor \"$orig_head\" \"$merge_head\" ||\n\t git merge-base --is-ancestor \"$merge_head\" \"$orig_head\")\n\nin order to avoid printing the message when \"git pull\" does not fetch\nany new changes and the user has some new commits.\n"},{"id":"223666","messageId":"871u6v93a8.fsf@igel.home","threadId":"33899","inReplyTo":"20130718143009.GC2337@serenity.lan","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2013-07-18T17:38:39Z","receivedAt":"2013-07-18T17:38:39Z","isPatch":true,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"John Keeping writes:\n\n> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:\n>> diff --git a/git-pull.sh b/git-pull.sh\n>> index 638aabb..4a6a863 100755\n>> --- a/git-pull.sh\n>> +++ b/git-pull.sh\n>> @@ -264,6 +274,30 @@ case \"$merge_head\" in\n>> \t\tdie \"$(gettext \"Cannot rebase onto multiple branches\")\"\n>> \tfi\n>> \t;;\n>> +*)\n>> +\t# integrating with a single other history\n>> +\tmerge_head=${merge_head% }\n>> +\tif test -z \"$rebase$no_ff$ff_only${squash#--no-squash}\" &&\n>> +\t\ttest -n \"$orig_head\" &&\n>> +\t\t! $(git merge-base --is-ancestor \"$orig_head\" \"$merge_head\")\n>\n> I think this needs to be:\n>\n> \t! $(git merge-base --is-ancestor \"$orig_head\" \"$merge_head\" ||\n> \t git merge-base --is-ancestor \"$merge_head\" \"$orig_head\")\n\nNeither makes sense. You want to check the exit status of git\nmerge-base --is-ancestor, not execute its (empty) output as a command.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"223674","messageId":"7vmwpj3g0l.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"871u6v93a8.fsf@igel.home","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-18T18:00:10Z","receivedAt":"2013-07-18T18:00:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Schwab writes:\n\n> John Keeping writes:\n>\n>> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:\n>>> diff --git a/git-pull.sh b/git-pull.sh\n>>> index 638aabb..4a6a863 100755\n>>> --- a/git-pull.sh\n>>> +++ b/git-pull.sh\n>>> @@ -264,6 +274,30 @@ case \"$merge_head\" in\n>>> \t\tdie \"$(gettext \"Cannot rebase onto multiple branches\")\"\n>>> \tfi\n>>> \t;;\n>>> +*)\n>>> +\t# integrating with a single other history\n>>> +\tmerge_head=${merge_head% }\n>>> +\tif test -z \"$rebase$no_ff$ff_only${squash#--no-squash}\" &&\n>>> +\t\ttest -n \"$orig_head\" &&\n>>> +\t\t! $(git merge-base --is-ancestor \"$orig_head\" \"$merge_head\")\n>>\n>> I think this needs to be:\n>>\n>> \t! $(git merge-base --is-ancestor \"$orig_head\" \"$merge_head\" ||\n>> \t git merge-base --is-ancestor \"$merge_head\" \"$orig_head\")\n>\n> Neither makes sense. You want to check the exit status of git\n> merge-base --is-ancestor, not execute its (empty) output as a command.\n\nGaah. You are right.\n\nThanks for spotting.\n"},{"id":"223685","messageId":"7vvc471x1s.fsf_-_@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"7vmwpj3g0l.fsf@alter.siamese.dyndns.org","subject":"[PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-18T19:35:11Z","receivedAt":"2013-07-18T19:35:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Because it is so easy to let Git handle automatically a trivial\nmerge with \"git pull\", a person who is new to Git may not realize\nthat the project s/he is interacting with may prefer a \"rebase\"\nworkflow.\n\nAdd a safety valve to fail \"git pull\" that does not explicitly\nspecify what branch from which repository to integrate your history\nwith, when it is neither a fast-forward or \"already up-to-date\",\nuntil/unless the user expressed her preference between the two ways\nof integration.\n\nThis can be an irritating backward incompatible change for old\ntimers, but it can be a one time irritation by doing:\n\n git config --global pull.rebase false\n\nonce to say \"I will always --merge\", and they'd not even notice.\n\n http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=225326\n\nfor a full discussion.\n\nHelped-by: John Keeping \nSigned-off-by: Junio C Hamano \n---\n\n * This time with updates to the documentation and the test suite.\n\n Documentation/git-pull.txt | 9 ++++++++\n git-pull.sh | 40 +++++++++++++++++++++++++++++++++++-\n t/t5520-pull.sh | 51 ++++++++++++++++++++++++++++++++++++++++++++++\n t/t5524-pull-msg.sh | 2 +-\n 4 files changed, 100 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\nindex 24ab07a..86f5170 100644\n--- a/Documentation/git-pull.txt\n+++ b/Documentation/git-pull.txt\n@@ -97,6 +97,14 @@ must be given before the options meant for 'git fetch'.\n Options related to merging\n ~~~~~~~~~~~~~~~~~~~~~~~~~~\n \n+When `git pull` that does not explicitly specify what branch from\n+which repository is to be integrated with your history on the\n+command line, recent Git will refuse to work until you specify how\n+that integration should happen, either with a command line option\n+(`--merge` or `--rebase`) or a configuration variable (`pull.rebase`\n+or `branch..rebase`, which is the same as `--merge`\n+(`--rebase`) when set to `false` (`true`) respectively.\n+\n include::merge-options.txt[]\n \n :git-pull: 1\n@@ -119,6 +127,7 @@ It rewrites history, which does not bode well when you\n published that history already. Do *not* use this option\n unless you have read linkgit:git-rebase[1] carefully.\n \n+--merge::\n --no-rebase::\n \tOverride earlier --rebase.\n \ndiff --git a/git-pull.sh b/git-pull.sh\nindex 638aabb..88c198f 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -41,13 +41,21 @@ test -f \"$GIT_DIR/MERGE_HEAD\" && die_merge\n strategy_args= diffstat= no_commit= squash= no_ff= ff_only=\n log_arg= verbosity= progress= recurse_submodules= verify_signatures=\n merge_args= edit=\n+\n curr_branch=$(git symbolic-ref -q HEAD)\n curr_branch_short=\"${curr_branch#refs/heads/}\"\n+\n+# See if we are configured to rebase by default.\n+# The value $rebase is, throughout the main part of the code:\n+# (empty) - the user did not have any preference\n+# true - the user told us to integrate by rebasing\n+# false - the user told us to integrate by merging\n rebase=$(git config --bool branch.$curr_branch_short.rebase)\n if test -z \"$rebase\"\n then\n \trebase=$(git config --bool pull.rebase)\n fi\n+\n dry_run=\n while :\n do\n@@ -113,7 +121,8 @@ do\n \t-r|--r|--re|--reb|--reba|--rebas|--rebase)\n \t\trebase=true\n \t\t;;\n-\t--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)\n+\t--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase|\\\n+\t-m|--m|--me|--mer|--merg|--merge)\n \t\trebase=false\n \t\t;;\n \t--recurse-submodules)\n@@ -219,6 +228,7 @@ test true = \"$rebase\" && {\n \t\tfi\n \tdone\n }\n+\n orig_head=$(git rev-parse -q --verify HEAD)\n git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok \"$@\" || exit 1\n test -z \"$dry_run\" || exit 0\n@@ -264,6 +274,34 @@ case \"$merge_head\" in\n \t\tdie \"$(gettext \"Cannot rebase onto multiple branches\")\"\n \tfi\n \t;;\n+*)\n+\t# integrating with a single other history; be careful not to\n+\t# trigger this check when we will say \"fast-forward\" or \"already\n+\t# up-to-date\".\n+\tmerge_head=${merge_head% }\n+\tif test -z \"$rebase$no_ff$ff_only${squash#--no-squash}\" &&\n+\t\ttest -n \"$orig_head\" &&\n+\t\ttest $# = 0 &&\n+\t\t! git merge-base --is-ancestor \"$orig_head\" \"$merge_head\" &&\n+\t\t! git merge-base --is-ancestor \"$merge_head\" \"$orig_head\"\n+\tthen\n+echo >&2 \"orig-head was $orig_head\"\n+echo >&2 \"merge-head is $merge_head\"\n+git show >&2 --oneline -s \"$orig_head\" \"$merge_head\"\n+\n+\t\tdie \"The pull does not fast-forward; please specify\n+if you want to merge or rebase.\n+\n+Use either\n+\n+ git pull --rebase\n+ git pull --merge\n+\n+You can also use 'git config pull.rebase true' (if you want --rebase) or\n+'git config pull.rebase false' (if you want --merge) to set this once for\n+this project and forget about it.\"\n+\tfi\n+\t;;\n esac\n \n if test -z \"$orig_head\"\ndiff --git a/t/t5520-pull.sh b/t/t5520-pull.sh\nindex 6af6c63..1e91eca 100755\n--- a/t/t5520-pull.sh\n+++ b/t/t5520-pull.sh\n@@ -255,4 +255,55 @@ test_expect_success 'git pull --rebase against local branch' '\n \ttest file = \"$(cat file2)\"\n '\n \n+test_expect_success 'git pull that does not say how to integrate' '\n+\tgit checkout -b other master^1 &&\n+\t>new &&\n+\tgit add new &&\n+\tgit commit -m \"add new file\" &&\n+\n+\tgit checkout -b test-to-integrate master &&\n+\n+\ttest_config branch.test-to-integrate.remote . &&\n+\ttest_config branch.test-to-integrate.merge other &&\n+\n+\t# need real integration\n+\ttest_must_fail git pull &&\n+\tgit reset --hard master &&\n+\n+\n+\t# configuration is explicit enough\n+\tfor how in false true\n+\tdo\n+\t\ttest_config pull.rebase $how &&\n+\t\tgit pull &&\n+\t\tgit reset --hard master || break\n+\tdone &&\n+\n+\t# per branch configuration is explicit enough\n+\ttest_unconfig pull.rebase &&\n+\tfor how in false true\n+\tdo\n+\t\ttest_config branch.test-to-integrate.rebase $how &&\n+\t\tgit pull &&\n+\t\tgit reset --hard master || break\n+\tdone &&\n+\n+\ttest_unconfig pull.rebase &&\n+\ttest_unconfig branch.test-to-integrate &&\n+\n+\t# already up to date\n+\tgit reset --hard master &&\n+\tgit branch -f other master^1\n+\tgit pull &&\n+\n+\t# fast forward\n+\tgit reset --hard master &&\n+\tgit checkout -B other master &&\n+\t>new &&\n+\tgit add new &&\n+\tgit commit -m \"add new file\" &&\n+\tgit checkout -B test-to-integrate master &&\n+\tgit pull\n+'\n+\n test_done\ndiff --git a/t/t5524-pull-msg.sh b/t/t5524-pull-msg.sh\nindex 8cccecc..660714b 100755\n--- a/t/t5524-pull-msg.sh\n+++ b/t/t5524-pull-msg.sh\n@@ -25,7 +25,7 @@ test_expect_success setup '\n test_expect_success pull '\n (\n \tcd cloned &&\n-\tgit pull --log &&\n+\tgit pull --log --merge &&\n \tgit log -2 &&\n \tgit cat-file commit HEAD >result &&\n \tgrep Dollar result\n-- \n1.8.3.3-992-gf0e5e44\n"},{"id":"223730","messageId":"CAPig+cTXn4hdKoCjnNXmybNxYt0Bt_QuxsfFxiA5b0J1FxUUmQ@mail.gmail.com","threadId":"33899","inReplyTo":"7vvc471x1s.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2013-07-19T00:54:16Z","receivedAt":"2013-07-19T00:54:16Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Thu, Jul 18, 2013 at 3:35 PM, Junio C Hamano wrote:\n> Add a safety valve to fail \"git pull\" that does not explicitly\n> specify what branch from which repository to integrate your history\n> with, when it is neither a fast-forward or \"already up-to-date\",\n> until/unless the user expressed her preference between the two ways\n> of integration.\n> ---\n> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\n> index 24ab07a..86f5170 100644\n> --- a/Documentation/git-pull.txt\n> +++ b/Documentation/git-pull.txt\n> @@ -97,6 +97,14 @@ must be given before the options meant for 'git fetch'.\n> Options related to merging\n> ~~~~~~~~~~~~~~~~~~~~~~~~~~\n>\n> +When `git pull` that does not explicitly specify what branch from\n> +which repository is to be integrated with your history on the\n> +command line, recent Git will refuse to work until you specify how\n> +that integration should happen, either with a command line option\n> +(`--merge` or `--rebase`) or a configuration variable (`pull.rebase`\n> +or `branch..rebase`, which is the same as `--merge`\n> +(`--rebase`) when set to `false` (`true`) respectively.\n\nThis paragraph-long single sentence may be intimidating. Perhaps some\nsimplification is possible:\n\n As a safety measure, bare `git pull` (without repository or\n branch) needs to be told how to integrate pulled changes with\n your history; either via `--merge` or `--rebase`. Also see\n configuration variables `pull.rebase` and `branch..rebase`\n in linkgit:git-config[1].\n\nI intentionally omitted the true/false explanation of the\nconfiguration variables since the user can follow the link and read\nabout them. It also may make sense to drop mention of those variables\naltogether since they are already described (including link) in the\ndescription of --rebase.\n\nI also intentionally omitted \"recent Git\" since it's rather nebulous.\n"},{"id":"223778","messageId":"7vy592wmcs.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"CAPig+cTXn4hdKoCjnNXmybNxYt0Bt_QuxsfFxiA5b0J1FxUUmQ@mail.gmail.com","subject":"Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-19T16:22:43Z","receivedAt":"2013-07-19T16:22:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n>> +When `git pull` that does not explicitly specify what branch from\n>> +which repository is to be integrated with your history on the\n>> +command line, recent Git will refuse to work until you specify how\n>> +that integration should happen, either with a command line option\n>> +(`--merge` or `--rebase`) or a configuration variable (`pull.rebase`\n>> +or `branch..rebase`, which is the same as `--merge`\n>> +(`--rebase`) when set to `false` (`true`) respectively.\n>\n> This paragraph-long single sentence may be intimidating. Perhaps some\n> simplification is possible:\n>\n> As a safety measure, bare `git pull` (without repository or\n> branch) needs to be told how to integrate pulled changes with\n> your history; either via `--merge` or `--rebase`. Also see\n> configuration variables `pull.rebase` and `branch..rebase`\n> in linkgit:git-config[1].\n>\n> I intentionally omitted the true/false explanation of the\n> configuration variables since the user can follow the link and read\n> about them. It also may make sense to drop mention of those variables\n> altogether since they are already described (including link) in the\n> description of --rebase.\n>\n> I also intentionally omitted \"recent Git\" since it's rather nebulous.\n\nLooks much better than the original. I would further suggest\ndropping the \"As a safety measure, bare \" at the beginning.\n\n `git pull` (without repository or branch on the command line)\n needs to be told how to integrate the changes with your\n history via either `--merge` or `--rebase` (see configuration\n variables `pull.rebase` and `branch..rebase` in\n linkgit:git-config[1]).\n\nperhaps?\n"},{"id":"223803","messageId":"CAPig+cQEtKc+tfDgqVWYL2JtxXc=wvS=P7_O=XJzizz1BN=n4A@mail.gmail.com","threadId":"33899","inReplyTo":"7vy592wmcs.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2013-07-19T20:29:20Z","receivedAt":"2013-07-19T20:29:20Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Jul 19, 2013 at 12:22 PM, Junio C Hamano wrote:\n> Eric Sunshine writes:\n>\n>>> +When `git pull` that does not explicitly specify what branch from\n>>> +which repository is to be integrated with your history on the\n>>> +command line, recent Git will refuse to work until you specify how\n>>> +that integration should happen, either with a command line option\n>>> +(`--merge` or `--rebase`) or a configuration variable (`pull.rebase`\n>>> +or `branch..rebase`, which is the same as `--merge`\n>>> +(`--rebase`) when set to `false` (`true`) respectively.\n>>\n>> This paragraph-long single sentence may be intimidating. Perhaps some\n>> simplification is possible:\n>>\n>> As a safety measure, bare `git pull` (without repository or\n>> branch) needs to be told how to integrate pulled changes with\n>> your history; either via `--merge` or `--rebase`. Also see\n>> configuration variables `pull.rebase` and `branch..rebase`\n>> in linkgit:git-config[1].\n>>\n>> I intentionally omitted the true/false explanation of the\n>> configuration variables since the user can follow the link and read\n>> about them. It also may make sense to drop mention of those variables\n>> altogether since they are already described (including link) in the\n>> description of --rebase.\n>>\n>> I also intentionally omitted \"recent Git\" since it's rather nebulous.\n>\n> Looks much better than the original. I would further suggest\n> dropping the \"As a safety measure, bare \" at the beginning.\n>\n> `git pull` (without repository or branch on the command line)\n> needs to be told how to integrate the changes with your\n> history via either `--merge` or `--rebase` (see configuration\n> variables `pull.rebase` and `branch..rebase` in\n> linkgit:git-config[1]).\n>\n> perhaps?\n\nThat works; or without the mentioning the configuration variables at\nall (assuming the reader will discover them from reading --rebase\ndescription):\n\n `git pull` (without repository or branch on the command line)\n needs to be told how to integrate the changes with your history\n via either `--merge` or `--rebase`.\n\nDropping the parenthetical comment might improve flow slightly:\n\n Without repository or branch on the command line, `git pull`\n needs to be told how to integrate the changes with your history,\n via either `--merge` or `--rebase`.\n\nWith or without mention of the configuration options, either phrasing\nseems pretty easy to digest.\n"},{"id":"223806","messageId":"7vzjtitco6.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"CAPig+cQEtKc+tfDgqVWYL2JtxXc=wvS=P7_O=XJzizz1BN=n4A@mail.gmail.com","subject":"Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-19T22:20:09Z","receivedAt":"2013-07-19T22:20:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> Dropping the parenthetical comment might improve flow slightly:\n>\n> Without repository or branch on the command line, `git pull`\n> needs to be told how to integrate the changes with your history,\n> via either `--merge` or `--rebase`.\n>\n> With or without mention of the configuration options, either phrasing\n> seems pretty easy to digest.\n\nYeah, that reads much better, but I do prefer to see something that\nexplains this is often \"just make sure you use the one that suits\nyour project and always use that\". How about something like this?\n\n With no repository or branch on the command line, `git pull` needs\n to be told how to integrate the changes with your history.\n\n This can be done via either `--merge` or `--rebase` option, but most\n people would want to decide which method matches the workflow of the\n project once, and set the configuration variable `pull.rebase` or\n `branch..rebase` to stick to it; see linkgit:git-config[1].\n"},{"id":"223808","messageId":"CAPig+cT83Zv5aDDTYhfLOQ-ymCckwHDhxE6ChHUQKWQbfPdG6A@mail.gmail.com","threadId":"33899","inReplyTo":"7vzjtitco6.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2013-07-19T22:30:16Z","receivedAt":"2013-07-19T22:30:16Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, Jul 19, 2013 at 6:20 PM, Junio C Hamano wrote:\n> Eric Sunshine writes:\n>\n>> Dropping the parenthetical comment might improve flow slightly:\n>>\n>> Without repository or branch on the command line, `git pull`\n>> needs to be told how to integrate the changes with your history,\n>> via either `--merge` or `--rebase`.\n>>\n>> With or without mention of the configuration options, either phrasing\n>> seems pretty easy to digest.\n>\n> Yeah, that reads much better, but I do prefer to see something that\n> explains this is often \"just make sure you use the one that suits\n> your project and always use that\". How about something like this?\n>\n> With no repository or branch on the command line, `git pull` needs\n> to be told how to integrate the changes with your history.\n>\n> This can be done via either `--merge` or `--rebase` option, but most\n> people would want to decide which method matches the workflow of the\n> project once, and set the configuration variable `pull.rebase` or\n> `branch..rebase` to stick to it; see linkgit:git-config[1].\n\nAt this point, I'm probably just bike-shedding. Perhaps?\n\n With no repository or branch on the command line, `git pull`\n needs to be told how to integrate the changes with your history,\n via either `--merge` or `--rebase`.\n\n To match a project's workflow and make the choice of merge or\n rebase permanent, set configuration variable `pull.rebase` or\n `branch..rebase` (see linkgit:git-config[1]).\n"},{"id":"223810","messageId":"7vip06tb0i.fsf@alter.siamese.dyndns.org","threadId":"33899","inReplyTo":"CAPig+cT83Zv5aDDTYhfLOQ-ymCckwHDhxE6ChHUQKWQbfPdG6A@mail.gmail.com","subject":"Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-07-19T22:55:57Z","receivedAt":"2013-07-19T22:55:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n>> With no repository or branch on the command line, `git pull` needs\n>> to be told how to integrate the changes with your history.\n>>\n>> This can be done via either `--merge` or `--rebase` option, but most\n>> people would want to decide which method matches the workflow of the\n>> project once, and set the configuration variable `pull.rebase` or\n>> `branch..rebase` to stick to it; see linkgit:git-config[1].\n>\n> At this point, I'm probably just bike-shedding. Perhaps?\n>\n> With no repository or branch on the command line, `git pull`\n> needs to be told how to integrate the changes with your history,\n> via either `--merge` or `--rebase`.\n>\n> To match a project's workflow and make the choice of merge or\n> rebase permanent, set configuration variable `pull.rebase` or\n> `branch..rebase` (see linkgit:git-config[1]).\n\nI agree with the bike-shedding aspect of your comment, and actually\nI like my version better.\n\nIt makes it clear that a single-shot --merge or --rebase from the\ncommand line is not recommended. \"To match the project's workflow\"\nis not optional in most projects, and it is preferrable to decide\nonce and set the choice in stone.\n"},{"id":"226131","messageId":"CAMP44s0ggDXfQ0GeCOyRHb25TgUkUGT_OSt3K6u5Ua+EatqD=g@mail.gmail.com","threadId":"33899","inReplyTo":"7vvc4xluxt.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-08-28T23:22:42Z","receivedAt":"2013-08-28T23:22:42Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Jun 28, 2013 at 5:41 PM, Junio C Hamano wrote:\n> John Keeping writes:\n\n>> I don't think \"git pull remote branch\" falls into the same category as\n>> plain \"git pull\" so I'm not convinced that defaulting to merge there is\n>> unreasonable. The original message about this [1] did talk about only\n>> \"git pull\" with no arguments.\n>\n> If you want to limit the scope to only \"git pull\" (without any\n> command line argument), I actually do not have strong preference for\n> or against it either way. Perhaps a follow-up patch to be squashed?\n\nI do. Whether the user does 'git pull' or 'git pull origin' doesn't\nmatter, we still want to reject non-fast-forward merges.\n\n-- \nFelipe Contreras\n"},{"id":"233529","messageId":"1390417708472-7602383.post@n2.nabble.com","threadId":"33899","inReplyTo":"7vvc471x1s.fsf_-_@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull","fromName":"Flimm","fromEmail":"daviddlowe.flimm@gmail.com","sentAt":"2014-01-22T19:08:28Z","receivedAt":"2014-01-22T19:08:28Z","isPatch":true,"sender":{"key":"daviddlowe.flimm@gmail.com","avatar":null},"body":"Has this patch been released yet?\n\n\n\n--\nView this message in context: http://git.661346.n2.nabble.com/first-parent-commit-graph-layout-and-pull-merge-direction-tp7586671p7602383.html\nSent from the git mailing list archive at Nabble.com.\n"}]}