{"thread":{"id":"35838","subject":"Documentation about \"push.default=upstream\" is confusing","startedAt":"2014-02-09T16:31:57Z","lastAt":"2014-02-10T19:06:00Z","messageCount":2,"participants":["Ingo Rohloff","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"234551","messageId":"20140209163157.GA7652@localhost","threadId":"35838","inReplyTo":null,"subject":"Documentation about \"push.default=upstream\" is confusing","fromName":"Ingo Rohloff","fromEmail":"lundril@gmx.de","sentAt":"2014-02-09T16:31:57Z","receivedAt":"2014-02-09T16:31:57Z","isPatch":false,"sender":{"key":"lundril@gmx.de","avatar":null},"body":"Hello,\n\nI recently started to use git and now are digging through more and more\nof the low level details.\n\nWhat I recently tried was to do this for a repository created by Bob:\n\n  git remote add -t for_bob anna <url>\n\nSo setup a remote (created by anna) for which a branch called \n\"for_bob\" is fetched.\nThen \"git fetch anna\".\n\nThen\n  git checkout -b from_anna anna/for_bob\n\nSo create a \"from_anna\" branch in Bobs repository which tracks the \"for_bob\"\nbranch in the remote \"anna\" repository.\n\nNow \"git pull\" works as expected for the \"from_anna\" branch.\n\nBut \"git push\" does not, because \"from_anna\" has a different branch name\nthan the branch you want to push to (you want to push to the \"for_bob\"\nbranch).\n\nSo after googling I found out about the \"push.default=upstream\" config\noption, which seems to do exactly what I want: It uses the tracking\ninformation to decide to which remote branch I want to push.\n\nNow for cross checking I looked up the documentation of \"push.default\" at\nhttp://git-scm.com . It says:\n\n----- snip ------\npush.default ...\n\nupstream - push the current branch back to the branch whose changes are\nusually integrated into the current branch (which is called @{upstream}).\nThis mode only makes sense if you are pushing to the same repository you\nwould normally pull from (i.e. central workflow).\n\n----- snip -----\n\nI think the second sentence here is quite confusing.\nTo me it seems \"push.default=upstream\" is actually the best choice for a\n*de-centralized* workflow.\n\nRationale:\nAssume I pull the \"master\" branch from several remote repositories\n(de-centralized workflow I guess).\n\nTo handle that I setup several remote tracking branches called:\n  repo1_master   (tracks repo1/master)\n  repo2_master   (tracks repo2/master)\n  reap3_master   (tracks repo3/master)\n\nNow without \"push.default=upstream\" I would have to either always explicitly\ndo something like:\n  git push repo1 repo1_master:master\n  git push repo2 repo2_master:master\n\nOr modify \".git/config\" to add that per default via \"push=\" entries.\n\nWhereas with \"push.default=upstream\" everything works as expected it seems.\n\nSo if I am not wrong here, I would propose to rephrase the sentence\n------ snip -----\nThis mode only makes sense if you are pushing to the same repository you \nwould normally pull from (i.e. central workflow).\n------ snip -----\n\nTo do that: Could someone point out, when it does NOT make sense to use\n\"push.default=upstream\" ?\n\nwith best regards\n  Ingo\n"},{"id":"234591","messageId":"xmqqd2iuss87.fsf@gitster.dls.corp.google.com","threadId":"35838","inReplyTo":"20140209163157.GA7652@localhost","subject":"Re: Documentation about \"push.default=upstream\" is confusing","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-02-10T19:06:00Z","receivedAt":"2014-02-10T19:06:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ingo Rohloff <lundril@gmx.de> writes:\n\n> To handle that I setup several remote tracking branches called:\n>   repo1_master   (tracks repo1/master)\n>   repo2_master   (tracks repo2/master)\n>   reap3_master   (tracks repo3/master)\n>\n> Now without \"push.default=upstream\" I would have to either always explicitly\n> do something like:\n>   git push repo1 repo1_master:master\n>   git push repo2 repo2_master:master\n\nIf you think about your interaction with people who are only looking\nat \"repo1\" alone, you _are_ using a centralized workflow.  You are\nnot the only one who update their 'master'; other people push there\nto update that 'master' and you pull it in to keep you up to date\nand further build your changes on top.  Such an interaction with\nother people by using repo1 as the shared meeting point is well\nserved by the push-to-upstream mechanism, and that kind of\ninteraction is called \"centralized workflow\".  The illustration from\nyou is running one centralized workflow with each of the three\nrepositories.\n\nThe de-centralized workflow the message hints (but does not talk\nabout) is different.  It is not uncommon to pull from one place and\nthen to push the result out to your own publishing branch\n(e.g. clone from anna, fetch to keep up to date with her, work on\nit, publish to your repository to tell her to fetch from you), and\npush-to-upstream is not very well suited for that topology.  You may\nclone her \"for-bob\" branch, but you do not push it back to her\nrepository to update her \"for-bob\" branch.\n"}]}