{"thread":{"id":"11124","subject":"[BUG] Pulling tags no longer works in 1.5.3.4...","startedAt":"2007-12-04T02:00:15Z","lastAt":"2007-12-04T07:41:25Z","messageCount":4,"participants":["Jeff Garzik","Johannes Schindelin","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"61853","messageId":"4754B4AF.8070408@garzik.org","threadId":"11124","inReplyTo":null,"subject":"[BUG] Pulling tags no longer works in 1.5.3.4...","fromName":"Jeff Garzik","fromEmail":"jeff@garzik.org","sentAt":"2007-12-04T02:00:15Z","receivedAt":"2007-12-04T02:00:15Z","isPatch":false,"sender":{"key":"jeff@garzik.org","avatar":null},"body":"Using package git-core-1.5.3.3-3.fc7, I can do the following with kernel \ngit trees:\n\n1) git-clone --reference linux-2.6 linux-2.6 tmp-2.6\n\n2) time passes (days or weeks)\n\n3)\tcd tmp-2.6\n\tgit pull ../linux-2.6\n\tgit pull --tags ../linux-2.6\n\nResult: works as expected.\n\n\n\nUsing package git-core-1.5.3.4-1.fc8, step #3 breaks:\n\n[jgarzik@pretzel misc-2.6]$ git pull --tags ../linux-2.6/\nYou asked me to pull without telling me which branch you\nwant to merge with, and 'branch.master.merge' in\nyour configuration file does not tell me either. Please\nname which branch you want to merge on the command line and\ntry again (e.g. 'git pull ').\nSee git-pull(1) for details on the refspec.\n\nIf you often merge with the same branch, you may want to\nconfigure the following variables in your configuration\nfile:\n\n branch.master.remote = \n branch.master.merge = \n remote..url = \n remote..fetch = \n\nSee git-config(1) for details.\n"},{"id":"61858","messageId":"Pine.LNX.4.64.0712040220270.27959@racer.site","threadId":"11124","inReplyTo":"4754B4AF.8070408@garzik.org","subject":"Re: [BUG] Pulling tags no longer works in 1.5.3.4...","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-04T02:21:36Z","receivedAt":"2007-12-04T02:21:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 3 Dec 2007, Jeff Garzik wrote:\n\n> Using package git-core-1.5.3.3-3.fc7, I can do the following with kernel git\n> trees:\n> \n> 1) git-clone --reference linux-2.6 linux-2.6 tmp-2.6\n> \n> 2) time passes (days or weeks)\n> \n> 3)\tcd tmp-2.6\n> \tgit pull ../linux-2.6\n> \tgit pull --tags ../linux-2.6\n> \n> Result: works as expected.\n> \n> \n> \n> Using package git-core-1.5.3.4-1.fc8, step #3 breaks:\n> \n> [jgarzik@pretzel misc-2.6]$ git pull --tags ../linux-2.6/\n> You asked me to pull without telling me which branch you\n> want to merge with, and 'branch.master.merge' in\n> your configuration file does not tell me either. Please\n> name which branch you want to merge on the command line and\n> try again (e.g. 'git pull ').\n> See git-pull(1) for details on the refspec.\n\nOops.\n\nAs a workaround, please do \"git fetch --tags ../linux-2.6 && git pull \n../linux-2.6/\" until it is fixed.\n\nCiao,\nDscho\n"},{"id":"61861","messageId":"20071204023340.GA22320@coredump.intra.peff.net","threadId":"11124","inReplyTo":"4754B4AF.8070408@garzik.org","subject":"Re: [BUG] Pulling tags no longer works in 1.5.3.4...","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-12-04T02:33:40Z","receivedAt":"2007-12-04T02:33:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 03, 2007 at 09:00:15PM -0500, Jeff Garzik wrote:\n\n> Using package git-core-1.5.3.3-3.fc7, I can do the following with kernel git \n> trees:\n>\n> 1) git-clone --reference linux-2.6 linux-2.6 tmp-2.6\n>\n> 2) time passes (days or weeks)\n>\n> 3)\tcd tmp-2.6\n> \tgit pull ../linux-2.6\n> \tgit pull --tags ../linux-2.6\n>\n> Result: works as expected.\n\nHrm, when I try to reproduce using v1.5.3.3, I get the \"Warning: No\nmerge candidate found...\" message. Between 1.5.3.3 and 1.5.3.4, this\nmessage got a bit longer and the exit code was fixed to indicate an\nerror. Were you perhaps just missing the warning message, since no error\nwas signaled?\n\nAt any rate, I think what you really want in step 3 is\n\n git fetch --tags ../linux-2.6\n\nsince you just want to grab the tags, and not merge anything (remember\nthat pull is fetch+merge -- you are only interesting in the fetching\nside effect). You could also do this:\n\n git pull --tags ../linux-2.6 master\n\nIn general, \"git pull --tags\" without a branch to pull doesn't make much\nsense. What happens is that the \"--tags\" tells the fetch part of the\npull operation to just grab the tags. Then the merge part of the pull\noperation looks in what has just been fetched for something merge-able.\nAnd of course there isn't anything, since all you fetched were tags.\n\n-Peff\n"},{"id":"61874","messageId":"7v8x4a9aai.fsf@gitster.siamese.dyndns.org","threadId":"11124","inReplyTo":"4754B4AF.8070408@garzik.org","subject":"Re: [BUG] Pulling tags no longer works in 1.5.3.4...","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-04T07:41:25Z","receivedAt":"2007-12-04T07:41:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff Garzik writes:\n\n> \tgit pull ../linux-2.6\n> \tgit pull --tags ../linux-2.6\n\nThis is tricky, and in order to decide the right course of action, we\nneed to understand some background.\n\n\"git pull\" is defined as \"fetch the history missing at this end from the\nremote, and integrate the remote change to the current branch\".\n\n Side note. Historically, \"integrate ... to the current branch\" was\n defined as \"merge\", so I would have phrased the above as \"pull is\n fetch followed by merge\", but I am being a bit careful here.\n Upcoming 1.5.4 will optionally allow you to rebase on top of what\n was fetched instead of merging.\n\nNow, your second \"git pull --tags\" is about fetching the tags but what\nis it integrating? Nothing. What you wanted to would have been\nexpressed much better with \"git fetch --tags\".\n\n Side note. My conclusion at the end would NOT be \"so your usage is\n wrong, do not complain\", so swallow the \"I do not care. This has\n always worked!\" for a while and read on.\n\n Side note. For a long time, the first \"git pull\" from a repository\n you track with tracking branches followed the tags automatically,\n and there shouldn't be any reason to do a separate \"fetch --tags\"\n these days.\n\nNow, what is integrated by \"integration of remote change into the\ncurrent branch\" step has long been defined as \"merge refspec explicitly\ngiven from the command line (if exists), otherwise use the first Pull:\nline in .git/remotes/ file or corresponding remote.*.fetch line in\n.git/config\", no matter which branch you are on. This traditional\ndefinition was fine as long as the puller stayed on the primary\nintegration branch.\n\nThen people started using multiple branches in a single repository a lot\nmore than before. Running \"git pull\" when you are on a branch that is\nnot your primary integration branch still merged the default branch you\nget from the remote into your current branch. This behaviour was\nunpopular. Users, especially with ones with shared repository workflow,\nwanted to have branches A and B at the remote to correspond to their\nlocal branches A and B, and wanted to merge A from the remote when they\nissued \"git pull\" while on branch A and remote B while on branch B.\n\nThis was made possible by allowing branch.*.merge configuration variable\nset for each branch to specify what remote branch to merge in during\ngit-pull. Everybody was happier. But the default stayed the same to\nhelp old timers (like us). Without such a configuration, \"first refspec\nconfigured\" rule still apply.\n\nNow, some users ran \"git pull\" without configuring branch.*.merge and\ngot the default (typically, \"master\") remote branch merged into the\nbranch they happened to have checked out. Again this was unpopular.\n\nSo there was an additional safety devised, early December 2006. If\nbranch.*.merge is not configured, \"git-pull\" may not find any remote\nbranch to merge to the current branch without being told explicitly from\nthe command line (i.e. \"git pull $there master\"). For such a case, the\nhelp message you saw is issued, instead of silently failing, to instruct\nthe user about the configuration variable. This message, from the point\nof view of users who complained about the unpopular behaviour described\nabove, was a bugfix. The earlier behaviour of not issuing any help\nmessage when you did \"git pull --tags\" was a bug.\n\nNow with that long background story in mind...\n\nStill, it does not make sense to \"integrate the changes reachable from\nthe tags to my current branch\" at all. While we could argue that use of\n\"git pull --tags\" is a nonsense to begin with, we can also argue that\nthe command line is saying \"I am not interested in integrating anything\nI got from the remote with this fetch\" explicitly from the command line.\n\nWe could just honor that and be silent in such a case, instead of giving\nthe message you saw.\n\nWe could do something like the following patch, but it does feel like a\nspecial hack to keep \"traditional misuse\" working, doesn't it?\n\n---\n git-pull.sh | 7 +++++++\n 1 files changed, 7 insertions(+), 0 deletions(-)\n\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 74bfc16..00f73d1 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -97,6 +97,13 @@ case \"$merge_head\" in\n \tesac\n \tcurr_branch=${curr_branch#refs/heads/}\n \n+\tnontag=$(sed -e '/\tnot-for-merge\ttag/d' \"$GIT_DIR/FETCH_HEAD\")\n+\tcase \"$nontag\" in\n+\t'')\n+\t\texit 0 ;# git pull --tags\n+\t\t;;\n+\tesac\n+\n \techo >&2 \"You asked me to pull without telling me which branch you\"\n \techo >&2 \"want to merge with, and 'branch.${curr_branch}.merge' in\"\n \techo >&2 \"your configuration file does not tell me either. Please\"\n"}]}