{"thread":{"id":"25262","subject":"git push on tracking branches","startedAt":"2010-09-27T16:00:41Z","lastAt":"2010-09-27T17:53:39Z","messageCount":5,"participants":["Stephen Bash","Jeff King","Nick"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"151832","messageId":"15793457.371451.1285603241207.JavaMail.root@mail.hq.genarts.com","threadId":"25262","inReplyTo":"6958088.371432.1285602164529.JavaMail.root@mail.hq.genarts.com","subject":"git push on tracking branches","fromName":"Stephen Bash","fromEmail":"bash@genarts.com","sentAt":"2010-09-27T16:00:41Z","receivedAt":"2010-09-27T16:00:41Z","isPatch":false,"sender":{"key":"bash@genarts.com","avatar":null},"body":"Hi all-\n\nA coworker alerted me to some strange behavior with git push on tracking branches (maybe a documentation error?).  Pro Git (http://progit.org/book/ch3-5.html) says:\n\n\"To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name:\n   $ git checkout -b sf origin/serverfix\n   Branch sf set up to track remote branch refs/remotes/origin/serverfix.\n   Switched to a new branch \"sf\"\nNow, your local branch sf will automatically push to and pull from origin/serverfix.\"\n\nWhen I do this on my local machine (current master on Mac 10.6.4):\n\nsnowg5-2:temp stephen$ git clone ssh://bash@penguin/home/git/repos/test-repo.git\nCloning into test-repo...\nwarning: templates not found /Users/stephen/share/git-core/templates\nremote: Counting objects: 100109, done.\nremote: Compressing objects: 100% (23394/23394), done.\nremote: Total 100109 (delta 76733), reused 99567 (delta 76231)\nReceiving objects: 100% (100109/100109), 620.24 MiB | 28.36 MiB/s, done.\nResolving deltas: 100% (76733/76733), done.\nsnowg5-2:temp stephen$ cd test-repo\nsnowg5-2:test-repo stephen$ git checkout -b tmp origin/real-branch-name\nBranch tmp set up to track remote branch real-branch-name from origin.\nSwitched to a new branch 'tmp'\n... edit some files ...\nsnowg5-2:test-repo stephen$ git add -u .\nsnowg5-2:test-repo stephen$ git commit -m \"made some changes\"\n[tmp 0440ace] made some changes\n 1 files changed, 1 insertions(+), 0 deletions(-)\nsnowg5-2:test-repo stephen$ git push\nEverything up-to-date\nsnowg5-2:test-repo stephen$ git rev-parse tmp\n0440ace51b4ab18eee39305cd2af070f572e38d7\nsnowg5-2:test-repo stephen$ git ls-remote origin real-branch-name\n92ebff3a7c332079bcbf84e9cf699ab635e6ba3c\trefs/heads/real-branch-name\nsnowg5-2:test-repo stephen$ git --version\ngit version 1.7.3.2.g9027fa\nsnowg5-2:test-repo stephen$ \n\nGit doesn't push the change.  If I either use \n  a) git checkout --track origin/real-branch-name \nor\n  b) git checkout -b real-branch-name origin/real-branch-name\nthe push succeeds.\n\nWas the behavior of git push intentionally changed or is this a bug?\n\nThanks,\nStephen\n"},{"id":"151834","messageId":"20100927160548.GA10256@sigill.intra.peff.net","threadId":"25262","inReplyTo":"15793457.371451.1285603241207.JavaMail.root@mail.hq.genarts.com","subject":"Re: git push on tracking branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-09-27T16:05:48Z","receivedAt":"2010-09-27T16:05:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 27, 2010 at 12:00:41PM -0400, Stephen Bash wrote:\n\n> A coworker alerted me to some strange behavior with git push on tracking branches (maybe a documentation error?).  Pro Git (http://progit.org/book/ch3-5.html) says:\n> \n> \"To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name:\n>    $ git checkout -b sf origin/serverfix\n>    Branch sf set up to track remote branch refs/remotes/origin/serverfix.\n>    Switched to a new branch \"sf\"\n> Now, your local branch sf will automatically push to and pull from origin/serverfix.\"\n\nThat has never been the case by default. Push has always defaulted to\npushing all matching branches (so of course if you use the same name, it\nwill end up pushing to the tracking branch).  However, you can do:\n\n  git config --global push.default tracking\n\nto explicitly change the default to push the current branch to its\nupstream. See the entry for \"push.default\" in \"git help config\".\n\nIt may be that Pro Git suggested setting up that config earlier. If not,\nyou should probably submit a bug report for the book.\n\n-Peff\n"},{"id":"151836","messageId":"29138507.371458.1285604041100.JavaMail.root@mail.hq.genarts.com","threadId":"25262","inReplyTo":"20100927160548.GA10256@sigill.intra.peff.net","subject":"Re: git push on tracking branches","fromName":"Stephen Bash","fromEmail":"bash@genarts.com","sentAt":"2010-09-27T16:14:01Z","receivedAt":"2010-09-27T16:14:01Z","isPatch":false,"sender":{"key":"bash@genarts.com","avatar":null},"body":"----- Original Message -----\n> From: \"Jeff King\" <peff@peff.net>\n> To: \"Stephen Bash\" <bash@genarts.com>\n> Cc: \"Git Mailing List\" <git@vger.kernel.org>\n> Sent: Monday, September 27, 2010 12:05:48 PM\n> Subject: Re: git push on tracking branches\n> On Mon, Sep 27, 2010 at 12:00:41PM -0400, Stephen Bash wrote:\n>\n> > Now, your local branch sf will automatically push to and pull from\n> > origin/serverfix.\"\n> \n> That has never been the case by default. Push has always defaulted to\n> pushing all matching branches (so of course if you use the same name,\n> it\n> will end up pushing to the tracking branch). However, you can do:\n> \n> git config --global push.default tracking\n> \n> to explicitly change the default to push the current branch to its\n> upstream. See the entry for \"push.default\" in \"git help config\".\n\nThanks for the clarification!\n\nStephen\n"},{"id":"151845","messageId":"4CA0D178.6070704@letterboxes.org","threadId":"25262","inReplyTo":"20100927160548.GA10256@sigill.intra.peff.net","subject":"Re: git push on tracking branches","fromName":"Nick","fromEmail":"oinksocket@letterboxes.org","sentAt":"2010-09-27T17:16:40Z","receivedAt":"2010-09-27T17:16:40Z","isPatch":false,"sender":{"key":"oinksocket@letterboxes.org","avatar":null},"body":"On 27/09/10 17:05, Jeff King wrote:\n> On Mon, Sep 27, 2010 at 12:00:41PM -0400, Stephen Bash wrote:\n> \n>> A coworker alerted me to some strange behavior with git push on tracking branches (maybe a documentation error?).  Pro Git (http://progit.org/book/ch3-5.html) says:\n>>\n>> \"To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name:\n>>    $ git checkout -b sf origin/serverfix\n>>    Branch sf set up to track remote branch refs/remotes/origin/serverfix.\n>>    Switched to a new branch \"sf\"\n>> Now, your local branch sf will automatically push to and pull from origin/serverfix.\"\n> \n> That has never been the case by default. Push has always defaulted to\n> pushing all matching branches (so of course if you use the same name, it\n> will end up pushing to the tracking branch).  However, you can do:\n> \n>   git config --global push.default tracking\n> \n> to explicitly change the default to push the current branch to its\n> upstream. See the entry for \"push.default\" in \"git help config\".\n\nThe \"tracking\" setting does seem more sensible and intuitive, given that current\ngit practice requires setting up explicit tracking relationships between branches.\n\nFor example, I find it surprising, perhaps even alarming, that by default, git\nwill try and push my changes on branch A to the branch origin/A - even if I\ncreated it to track origin/B.  Why allow the possibility of A tracking a\nnon-matching branch origin/B, and have the default push setting ignore that?\n\nNot only that, but I frequently get asked by puzzled colleagues, new to git, why\n\"git push\" seems to fail all the time when they're pushing their changes.  (The\nerrors arise because of the default \"matching\" setting: many of the matching\nbranches fail to push cleanly because the remote branch has silently changed. My\nlatest answer is to tell them to set push.default to \"tracking\", or to do that\nfor them.)\n\n\nI'm curious: why isn't \"tracking\" the default and recommended option?\n\"Historical reasons\" might explain the first, but not the second.\n\n\n- Nick\n"},{"id":"151848","messageId":"20100927175339.GA10650@sigill.intra.peff.net","threadId":"25262","inReplyTo":"4CA0D178.6070704@letterboxes.org","subject":"Re: git push on tracking branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-09-27T17:53:39Z","receivedAt":"2010-09-27T17:53:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Sep 27, 2010 at 06:16:40PM +0100, Nick wrote:\n\n> The \"tracking\" setting does seem more sensible and intuitive, given that current\n> git practice requires setting up explicit tracking relationships between branches.\n\nIt depends on your workflow. If you consider push to be a way of moving\ncommits in your private repo to a public publishing point, then matching\nmakes a lot more sense. But if you are emulating a centralized VCS\ntopology where you replace \"svn commit\" with \"git commit && git push\",\nthen probably pushing HEAD or \"tracking\" makes more sense.\n\nThe former is how git was originally conceived by Linus, and how many\npeople still use it (notably the kernel and git itself work this way).\nBut obviously yes, there are lots of people who use it more in the\nlatter way.\n\n> For example, I find it surprising, perhaps even alarming, that by default, git\n> will try and push my changes on branch A to the branch origin/A - even if I\n> created it to track origin/B.  Why allow the possibility of A tracking a\n> non-matching branch origin/B, and have the default push setting ignore that?\n\nWhat if I create a topic branch from the master branch, like:\n\n  $ git checkout -b topic origin/master\n\nNow I want to publish my topic for others to see. What should the\nbehavior be?\n\nWith matching, I can do:\n\n  $ hack hack hack\n  $ git push ;# oops, we push nothing, because topic is not\n              # already published\n  $ git push origin topic ;# now topic is published under its\n                           # own name\n  $ hack hack hack\n  $ git push ;# topic is synced to its published version,\n              # even though its upstream remains origin/master\n\nWith tracking, I get:\n\n  $ hack hack hack\n  $ git push ;# we just pushed topic commits to master!\n\nSo again. It depends on workflow. Do you think of a branch with a\ndifferent name than its upstream as a separate topic based on that\nupstream? Or do you think of it as a local version of upstream, simply\nwith a different name?\n\n> Not only that, but I frequently get asked by puzzled colleagues, new to git, why\n> \"git push\" seems to fail all the time when they're pushing their changes.  (The\n> errors arise because of the default \"matching\" setting: many of the matching\n> branches fail to push cleanly because the remote branch has silently changed. My\n> latest answer is to tell them to set push.default to \"tracking\", or to do that\n> for them.)\n\nYeah, one confusing aspect of matching is that it pushes things besides\nthe HEAD you are on. But I would argue that setting push.default to\n\"current\" is safer than tracking. It pushes only HEAD to a ref of the\nsame name. In the case that you name your branch after the upstream\nbranch, this is the same as tracking. In the case that you have named it\nsomething else, it assumes it is acting as a feature branch built on the\nupstream, but will never accidentally push feature commits onto the\nupstream branch.\n\n> I'm curious: why isn't \"tracking\" the default and recommended option?\n> \"Historical reasons\" might explain the first, but not the second.\n\nHistorical reasons. :)\n\nIf you want to read more, there was a lot of discussion on this about a\nyear and a half ago, which led to push.default being created. My quick\nsearch came up with this thread:\n\n  http://thread.gmane.org/gmane.comp.version-control.git/112757\n\nbut I seem to recall there being more philosophical discussion around\nthe topic, too. You might have to dig around in that general timeframe\nof the list archive.\n\n-Peff\n"}]}