{"thread":{"id":"33826","subject":"[RFC] New kind of upstream branch: base branch","startedAt":"2013-05-15T20:28:22Z","lastAt":"2013-05-15T23:32:32Z","messageCount":7,"participants":["Felipe Contreras","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"217476","messageId":"5193efe6.c42ab60a.0319.5f2c@mx.google.com","threadId":"33826","inReplyTo":null,"subject":"[RFC] New kind of upstream branch: base branch","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-15T20:28:22Z","receivedAt":"2013-05-15T20:28:22Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nI've been using Git from the start, but only lately have I forced myself to\nconfigure upstream branches for all my branches, and I've found a few things\nmore convenient, but others completely contrary to what I expected.\n\nInconvenient:\n\nBefore, I used to do 'git fetch' to simply fetch from 'origin', but now, it\ndepends on where 'upstream' is set to.\n\nConvinient:\n\nNow, I can just do 'git rebase --interactive' and I don't have to specify the\nstarting point, which is particularily useful when there's a lot of branches\none depending on another.\n\nI think I'm using 'upstream' for something it was not intended to, and I think\nthe current 'upstream' behavior should be split into 'upstream' and 'base'.\n\n== base ==\n\nThe 'base' branch will be set each time you create a branch from another;\n'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.\n\nThen you can do 'git rebase foobar@{base}' or simply 'git rebase', and Git will\npick the right branch to rebase unto, even if you have no 'upstream'\nconfigured.\n\nThis way 'git fetch' will keep picking 'origin', and other commands that make\nuse of 'upstrem' would be undisturbed.\n\nIf both 'base' and 'upstream' are defined, I think 'git rebase' should use\n'base', but since that would break old behavior, perhaps there should be a\nconfiguration variable to enable a different behavior.\n\nI already started writting the patches, and although tedious, I think they\nthey'll be rather straightforward, but I thought it would be best to hear some\nopinions first.\n\nWhat do you think?\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"217478","messageId":"7vzjvvanro.fsf@alter.siamese.dyndns.org","threadId":"33826","inReplyTo":"5193efe6.c42ab60a.0319.5f2c@mx.google.com","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-15T22:20:27Z","receivedAt":"2013-05-15T22:20:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> The 'base' branch will be set each time you create a branch from another;\n> 'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.\n\n\"git checkout -t -b foobar mastee\" would instead set 'upstream' of\n'foobar' to the branch 'master' of remote '.' (the current one).\nThis 'base' is a new mechanism to explicitly say \"The upstream of\nthis branch lives locally\" by not setting \"branch.foobar.remote\".\n\n> Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and Git will\n> pick the right branch to rebase unto, even if you have no 'upstream'\n> configured.\n\nSurely you can teach rebase to pay attention to 'base' and achieve\nthat.  But you can already do so with upstream, so this is not an\nadvertisement of a 'plus', but rather a lack of 'minus' (which is\nnot a bad thing at all).\n\n> This way 'git fetch' will keep picking 'origin', and other commands that make\n> use of 'upstrem' would be undisturbed.\n\nAnd this is the true plus, because 'git fetch' with the current\n\"setting a local base using the same upstream mechanism to point at\na branch of _this_ repository, indirectly setting the upstream\n_repository_ for this branch to the current repository\" will end up\nmaking you fetch from yourself, which is not very interesting.\n\nSo I think I understand your itch and I agree that it is a valid\none.\n\nI however am not yet convinced if that direction is what you really\nwant go in, though.  What should your 'git pull' on that branch do,\nfor example?\n\nWhen you are on foobar and want to integrate with the branch you\nbased your work on (i.e. local 'master'), you can do one of these:\n\n    $ git pull\n    $ git pull --rebase\n\nto \"fetch the upstream branch and integrate with it\", without having\nto even care if that upstream branch is from the remote, or happens\nto be truly local.  By making 'git fetch' to go to the remote origin\nsite, what will you be merging (or rebasing on) when you do the\nabove two?\n\nIncidentally, I suspect you can do exactly the same thing without\nintroducing a new concept \"base\" and instead special casing a remote\nwhose URL is \".\"; you essentially declare that \"The upstream of this\nbranch whose branch.$name.remote is set to '.' lives locally\", which\nis not all that different from saying \"The upstream of this branch\nwhose branch.$name.base exists lives locally\", which is what you\nseem to be proposing.  One of the things this alternative approach\nwould \"special case\" such remote is probably to cause \"git fetch\" to\nignore such a branch.$name.remote setting and instead go fetch from\n'origin', just like your \"if there is branch.$name.base, but no\nbranch.$name.remote, fetch will go to 'origin'\" does.\n\nBut it has exactly the same \"what happens when you do 'git pull'\"\nproblem, so even though it is conceptually a lot simpler, it has the\nsame brokenness.\n"},{"id":"217481","messageId":"7vvc6jame7.fsf@alter.siamese.dyndns.org","threadId":"33826","inReplyTo":"7vzjvvanro.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-15T22:50:08Z","receivedAt":"2013-05-15T22:50:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> I however am not yet convinced if that direction is what you really\n> want go in, though.  What should your 'git pull' on that branch do,\n> for example?\n>\n> When you are on foobar and want to integrate with the branch you\n> based your work on (i.e. local 'master'), you can do one of these:\n>\n>     $ git pull\n>     $ git pull --rebase\n>\n> to \"fetch the upstream branch and integrate with it\", without having\n> to even care if that upstream branch is from the remote, or happens\n> to be truly local.  By making 'git fetch' to go to the remote origin\n> site, what will you be merging (or rebasing on) when you do the\n> above two?\n>\n> Incidentally, I suspect you can do exactly the same thing without\n> introducing a new concept \"base\" and instead special casing a remote\n> whose URL is \".\"; you essentially declare that \"The upstream of this\n> branch whose branch.$name.remote is set to '.' lives locally\", which\n> is not all that different from saying \"The upstream of this branch\n> whose branch.$name.base exists lives locally\", which is what you\n> seem to be proposing.  One of the things this alternative approach\n> would \"special case\" such remote is probably to cause \"git fetch\" to\n> ignore such a branch.$name.remote setting and instead go fetch from\n> 'origin', just like your \"if there is branch.$name.base, but no\n> branch.$name.remote, fetch will go to 'origin'\" does.\n>\n> But it has exactly the same \"what happens when you do 'git pull'\"\n> problem, so even though it is conceptually a lot simpler, it has the\n> same brokenness.\n\nI do not think of a good way to fix the 'git pull' confusion; the\ndesire to 'fetch from the overall upstream repository regardless of\nwhich branch I am on' is a valid and understandable one, but that\ndoes not mesh well with \"'git pull' is 'git fetch' followed by\neither merge or rebase to integrate the result\" and \"git merge or\ngit rebase pays attention to the other branch that is specified to\nintegrate with\".  The best we could do might be to simply forbid\n\"git pull\" if your current branch is marked with branch.$name.base\nbut still allow \"git fetch\".\n\nThe changes that are involved are:\n\n * Do not change anything to @{upstream}'s definition, that is,\n   \"checkout -t -b A localbranch\" will set branch.A.remote to '.',\n   and \"git log A@{u}..A\" will stand for \"git log localbranch..A\".\n\n * Current 'git fetch' pays attention to branch.A.remote when you\n   are on branch A, and tries to fetch from there.  Stop doing that\n   when branch.A.remote is set to '.' (the current repository) and\n   let other rules in the current implementation decide what remote\n   to fetch from. Also teach it to error out when branch.A.remote is\n   set to '.' when a new --forbid-local option is passed.\n\n * Teach 'git pull' to pass --forbid-local option to 'git fetch',\n   and let an error return fail the whole thing.\n\nAh, alternatively, instead of adding --forbid-local, we could modify\nthe changes for 'git fetch' and 'git pull' to read like this:\n\n * Current 'git fetch' pays attention to branch.A.remote when you\n   are on branch A, and tries to fetch from there.  Stop doing that\n   when branch.A.remote is set to '.' (the current repository) and\n   let other rules in the current implementation decide what remote\n   to fetch from, unless a new --allow-fetch-from-local option is\n   passed.\n\n * Teach 'git pull' to pass --allow-fetch-from-local to 'git fetch'.\n\nIf we did this, we can keep the \"git pull [--rebase]\" as a way to\nintegrate with what you specified as your upstream, which is a\ncommon expectation, without forcing you to say \"git fetch origin\".\n"},{"id":"217482","messageId":"CAMP44s1kWkNgFMAvThczCvTZppWGca0YvGv=CQ15GtViA1zy_Q@mail.gmail.com","threadId":"33826","inReplyTo":"7vzjvvanro.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-15T22:56:56Z","receivedAt":"2013-05-15T22:56:56Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 15, 2013 at 5:20 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>> The 'base' branch will be set each time you create a branch from another;\n>> 'git checkout -b foobar master' sets 'master' as the 'base' of 'foobar'.\n>\n> \"git checkout -t -b foobar mastee\" would instead set 'upstream' of\n> 'foobar' to the branch 'master' of remote '.' (the current one).\n\nYeah, but I don't to set an upstream, because 'master' is not the\nupstream of 'foobar'.\n\n> This 'base' is a new mechanism to explicitly say \"The upstream of\n> this branch lives locally\" by not setting \"branch.foobar.remote\".\n\nNo, 'base' can point to a remote tracking branch.\n\n>> Then you can do 'git rebase foobar@{base}' or simply 'git rebase', and Git will\n>> pick the right branch to rebase unto, even if you have no 'upstream'\n>> configured.\n>\n> Surely you can teach rebase to pay attention to 'base' and achieve\n> that.  But you can already do so with upstream, so this is not an\n> advertisement of a 'plus', but rather a lack of 'minus' (which is\n> not a bad thing at all).\n\nOnly if there's an upstream configured, which many times is not the\ncase, and many times causes side-effects the user doesn't want to.\n\nThe purpose of 'upstream' is completely different.\n\n>> This way 'git fetch' will keep picking 'origin', and other commands that make\n>> use of 'upstrem' would be undisturbed.\n>\n> And this is the true plus, because 'git fetch' with the current\n> \"setting a local base using the same upstream mechanism to point at\n> a branch of _this_ repository, indirectly setting the upstream\n> _repository_ for this branch to the current repository\" will end up\n> making you fetch from yourself, which is not very interesting.\n>\n> So I think I understand your itch and I agree that it is a valid\n> one.\n>\n> I however am not yet convinced if that direction is what you really\n> want go in, though.  What should your 'git pull' on that branch do,\n> for example?\n\nExactly the same as 'git pull' does right now.\n\n'base' has absolutely nothing to do with pulling or pushing.\n\n> When you are on foobar and want to integrate with the branch you\n> based your work on (i.e. local 'master'), you can do one of these:\n>\n>     $ git pull\n>     $ git pull --rebase\n>\n> to \"fetch the upstream branch and integrate with it\", without having\n> to even care if that upstream branch is from the remote, or happens\n> to be truly local.  By making 'git fetch' to go to the remote origin\n> site, what will you be merging (or rebasing on) when you do the\n> above two?\n\nThe same as we do now.\n\n> Incidentally, I suspect you can do exactly the same thing without\n> introducing a new concept \"base\" and instead special casing a remote\n> whose URL is \".\"; you essentially declare that \"The upstream of this\n> branch whose branch.$name.remote is set to '.' lives locally\", which\n> is not all that different from saying \"The upstream of this branch\n> whose branch.$name.base exists lives locally\", which is what you\n> seem to be proposing.\n\nThat would be good, but it doesn't have the same benefits:\n\nIf I have set an 'upstream' branch, say 'github/master', and I have\n'base' branch, say 'origin/master'. I would expect 'git rebase' to\nrebase onto 'origin/master'. When I do 'git push', I expect to push to\n'github/master'. Moreover, I would expect 'git fetch' to fetch from\n'origin', but that can be discussed later.\n\nRight now I'm forced to choose a single branch and set it to\n'upstream'. If I choose 'origin/master' (which is not really the\nupstream), the rebase would do what I want, but not the push, unless I\nhave configured a remote.pushdefault, but that would only work if I\nthe real upstream is the common one. If I choose 'github/master', then\nrebase would not do what I want (and neither would fetch).\n\n> One of the things this alternative approach\n> would \"special case\" such remote is probably to cause \"git fetch\" to\n> ignore such a branch.$name.remote setting and instead go fetch from\n> 'origin', just like your \"if there is branch.$name.base, but no\n> branch.$name.remote, fetch will go to 'origin'\" does.\n>\n> But it has exactly the same \"what happens when you do 'git pull'\"\n> problem, so even though it is conceptually a lot simpler, it has the\n> same brokenness.\n\nThere is no brokenness; 'git pull' does different things depending on\nthe configuration. With my proposal nothing would change.\n\n-- \nFelipe Contreras\n"},{"id":"217483","messageId":"7vr4h7al9k.fsf@alter.siamese.dyndns.org","threadId":"33826","inReplyTo":"CAMP44s1kWkNgFMAvThczCvTZppWGca0YvGv=CQ15GtViA1zy_Q@mail.gmail.com","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-15T23:14:31Z","receivedAt":"2013-05-15T23:14:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> Exactly the same as 'git pull' does right now.\n\nYou set\n\n\t[branch 'foobar']\n        \tbase = refs/heads/master\n\nthen 'git pull [--rebase]' will go to 'origin' due to the default,\nbut then what branch from the 'origin' are you integrating with?\n\nDo you mean you are also setting both remote and upstream, perhaps\nlike this, for all of your branches?\n\n\t[remote \"origin\"]\n\t\turl = github.com:maintainer/hisproject\n                fetch = +refs/heads/*:refs/remotes/origin/*\n\n\t[remote \"github\"]\n        \turl = github.com:felipec/myproject\n                fetch = +refs/heads/*:refs/remotes/github/*\n\n\t[branch 'foobar']\n        \tbase = refs/heads/master\n\t\tremote = github ;# or is it origin???\n                upstream = refs/heads/foobar\n\nThen your 'git pull' will fetch from remote 'origin' and integrate\nwith its 'foobar' and 'push' may go to update 'foobar' at 'github'.\n\nPerhaps that is what you meant.\n\n> 'base' has absolutely nothing to do with pulling or pushing.\n\nI agree it shouldn't have anything to do with pushing, but given\nthat 'git pull [--rebase]' is a way to do a 'merge' or 'rebase' with\nwhat you 'git fetch', introducing something that 'merge' or 'rebase'\npays attention to that does not have anything to do with 'pull'\nsounds like it breaks existing end user expectation.\n\nBut that does not mean it is a bad idea. The behaviour changes only\nwhen you have branch.$name.base, so I suspect that we do not need to\nworry about \"what if the user has both?\" case you mentioned in your\nfirst message.\n\nI think I misunderstood what you meant.  If it is the norm to have\nboth base and upstream/remote in branch.$name (as opposed to \"have\nonly branch.$name.base and not branch.$name.remote to force fetch to\ngo to the default 'origin'), then 'git pull' will not break and I\ncan see how many things would work naturally (admittedly I can only\nsay 'many things', not 'everything', at this point, as I haven't\nthought things through).\n"},{"id":"217484","messageId":"CAMP44s2BXoUWGPWof+0u6=_UQXpPjA3jtBh0sKS+hhsd-=ViVg@mail.gmail.com","threadId":"33826","inReplyTo":"7vvc6jame7.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-15T23:18:47Z","receivedAt":"2013-05-15T23:18:47Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 15, 2013 at 5:50 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> I however am not yet convinced if that direction is what you really\n>> want go in, though.  What should your 'git pull' on that branch do,\n>> for example?\n>>\n>> When you are on foobar and want to integrate with the branch you\n>> based your work on (i.e. local 'master'), you can do one of these:\n>>\n>>     $ git pull\n>>     $ git pull --rebase\n>>\n>> to \"fetch the upstream branch and integrate with it\", without having\n>> to even care if that upstream branch is from the remote, or happens\n>> to be truly local.  By making 'git fetch' to go to the remote origin\n>> site, what will you be merging (or rebasing on) when you do the\n>> above two?\n>>\n>> Incidentally, I suspect you can do exactly the same thing without\n>> introducing a new concept \"base\" and instead special casing a remote\n>> whose URL is \".\"; you essentially declare that \"The upstream of this\n>> branch whose branch.$name.remote is set to '.' lives locally\", which\n>> is not all that different from saying \"The upstream of this branch\n>> whose branch.$name.base exists lives locally\", which is what you\n>> seem to be proposing.  One of the things this alternative approach\n>> would \"special case\" such remote is probably to cause \"git fetch\" to\n>> ignore such a branch.$name.remote setting and instead go fetch from\n>> 'origin', just like your \"if there is branch.$name.base, but no\n>> branch.$name.remote, fetch will go to 'origin'\" does.\n>>\n>> But it has exactly the same \"what happens when you do 'git pull'\"\n>> problem, so even though it is conceptually a lot simpler, it has the\n>> same brokenness.\n>\n> I do not think of a good way to fix the 'git pull' confusion; the\n> desire to 'fetch from the overall upstream repository regardless of\n> which branch I am on' is a valid and understandable one, but that\n> does not mesh well with \"'git pull' is 'git fetch' followed by\n> either merge or rebase to integrate the result\"\n\nBut that is not true. It's only true when merge.defaulttoupstream=true.\n\n> and \"git merge or\n> git rebase pays attention to the other branch that is specified to\n> integrate with\".  The best we could do might be to simply forbid\n> \"git pull\" if your current branch is marked with branch.$name.base\n> but still allow \"git fetch\".\n\nWhy forbid it? Why not leave it as it is?\n\n> The changes that are involved are:\n>\n>  * Do not change anything to @{upstream}'s definition, that is,\n>    \"checkout -t -b A localbranch\" will set branch.A.remote to '.',\n>    and \"git log A@{u}..A\" will stand for \"git log localbranch..A\".\n\nYes, but in addition it would set 'branch.A.base'.\n\n>  * Current 'git fetch' pays attention to branch.A.remote when you\n>    are on branch A, and tries to fetch from there.  Stop doing that\n>    when branch.A.remote is set to '.' (the current repository) and\n>    let other rules in the current implementation decide what remote\n>    to fetch from. Also teach it to error out when branch.A.remote is\n>    set to '.' when a new --forbid-local option is passed.\n\nI don't see the point of --forbid-local, but otherwise yeah.\n\n> Ah, alternatively, instead of adding --forbid-local, we could modify\n> the changes for 'git fetch' and 'git pull' to read like this:\n>\n>  * Current 'git fetch' pays attention to branch.A.remote when you\n>    are on branch A, and tries to fetch from there.  Stop doing that\n>    when branch.A.remote is set to '.' (the current repository) and\n>    let other rules in the current implementation decide what remote\n>    to fetch from, unless a new --allow-fetch-from-local option is\n>    passed.\n>\n>  * Teach 'git pull' to pass --allow-fetch-from-local to 'git fetch'.\n\nPerhaps.\n\n> If we did this, we can keep the \"git pull [--rebase]\" as a way to\n> integrate with what you specified as your upstream, which is a\n> common expectation, without forcing you to say \"git fetch origin\".\n\nI'm starting to change my mind. Perhaps instead of aiming to change\nthe behavior 'git rebase', it would make more sense to change the\nbehavior of 'git push'. So that 'git rebase', 'git fetch' and 'git\npull' all use 'upstream' as is currently the case, but 'git push'\nwould use something different. That would solve my 'origin/master' vs.\n'github/master' distinction. But I would like 'git checkout -b foo\nmaster' to automatically setup 'upstream', and 'git checkout -t -b foo\nmaster' to in addition set this other kind that only affects 'git\npush'. This would be a much more intrusive change though.\n\nSo, 'branch.A.merge' would become 'branch.A.upstream' and have the\nfull tracking branch (e.g. 'refs/remotes/github/master'), and\n'branch.A.remote' would only affect 'git push'.\n\n-- \nFelipe Contreras\n"},{"id":"217485","messageId":"CAMP44s3AwODeOE-D+xYyBQzu4TQfbs1P1N6tG4CW9w5LPH424A@mail.gmail.com","threadId":"33826","inReplyTo":"7vr4h7al9k.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] New kind of upstream branch: base branch","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2013-05-15T23:32:32Z","receivedAt":"2013-05-15T23:32:32Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, May 15, 2013 at 6:14 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>> Exactly the same as 'git pull' does right now.\n>\n> You set\n>\n>         [branch 'foobar']\n>                 base = refs/heads/master\n>\n> then 'git pull [--rebase]' will go to 'origin' due to the default,\n> but then what branch from the 'origin' are you integrating with?\n\nThe same as if you didn't have 'branch.foobar.base': none. You get an\nerror because there's no upstream.\n\n> Do you mean you are also setting both remote and upstream, perhaps\n> like this, for all of your branches?\n>\n>         [remote \"origin\"]\n>                 url = github.com:maintainer/hisproject\n>                 fetch = +refs/heads/*:refs/remotes/origin/*\n>\n>         [remote \"github\"]\n>                 url = github.com:felipec/myproject\n>                 fetch = +refs/heads/*:refs/remotes/github/*\n>\n>         [branch 'foobar']\n>                 base = refs/heads/master\n>                 remote = github ;# or is it origin???\n>                 upstream = refs/heads/foobar\n>\n> Then your 'git pull' will fetch from remote 'origin' and integrate\n> with its 'foobar' and 'push' may go to update 'foobar' at 'github'.\n>\n> Perhaps that is what you meant.\n\nThat's what I described in my example.\n\n>> 'base' has absolutely nothing to do with pulling or pushing.\n>\n> I agree it shouldn't have anything to do with pushing, but given\n> that 'git pull [--rebase]' is a way to do a 'merge' or 'rebase' with\n> what you 'git fetch', introducing something that 'merge' or 'rebase'\n> pays attention to that does not have anything to do with 'pull'\n> sounds like it breaks existing end user expectation.\n\nBut it's already broken.\n\n'git pull' is not the same as 'git fetch'+'git merge'. That *only*\nworks  when merge.defaulttoupstream is set.\n\n> But that does not mean it is a bad idea. The behaviour changes only\n> when you have branch.$name.base, so I suspect that we do not need to\n> worry about \"what if the user has both?\" case you mentioned in your\n> first message.\n\nIndeed. It wouldn't be an intrusive change; it would only affect 'git\nrebase', and nothing more.\n\nBut I'm wondering if the behavior of 'git fecth' should change as\nwell. And in fact it should be the other way around.\n\n> I think I misunderstood what you meant.  If it is the norm to have\n> both base and upstream/remote in branch.$name (as opposed to \"have\n> only branch.$name.base and not branch.$name.remote to force fetch to\n> go to the default 'origin'), then 'git pull' will not break and I\n> can see how many things would work naturally (admittedly I can only\n> say 'many things', not 'everything', at this point, as I haven't\n> thought things through).\n\nBut I think the norm would be to have only 'base', because a lot of\npeople don't manually set an upstream branch.\n\nIn the end it all boils down to; which is the upstream\n'origin/master', or 'github/master'? Well, it is 'origin/master', so\n'upstream' should point there, but I don't want to push to the\n'upstream', I want to push somewhere else by default.\n\n-- \nFelipe Contreras\n"}]}