{"thread":{"id":"4457","subject":"Problem upgrading to 1.4.0","startedAt":"2006-06-11T00:07:16Z","lastAt":"2006-06-13T07:10:31Z","messageCount":8,"participants":["Geoff Russell","Junio C Hamano","Pavel Roskin","Sean","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"21570","messageId":"93c3eada0606101707t5eb35a4du3ebd0fd17737943f@mail.gmail.com","threadId":"4457","inReplyTo":null,"subject":"Problem upgrading to 1.4.0","fromName":"Geoff Russell","fromEmail":"geoffrey.russell@gmail.com","sentAt":"2006-06-11T00:07:16Z","receivedAt":"2006-06-11T00:07:16Z","isPatch":false,"sender":{"key":"geoffrey.russell@gmail.com","avatar":"https://gravatar.com/avatar/c30f497ccfa6bf06d86f30bd2ba092a2dd124c61c6bc902f7cb5c3f6486947de?d=mp&s=160"},"body":"Hi,\n\nWhen I do a \"git pull origin\" I get messages:\n\n error: no such remote ref refs/heads/gb/diffdelta\n error: no such remote ref refs/heads/jc/bind\n error: no such remote ref refs/heads/jc/bind-2\n ...\n Fetch failure: git://git.kernel.org/pub/scm/git/git.git\n\nSo I figured these branches were \"in the way\" so I deleted them:\n\n git branch -D gb/diffdelta\n etc.\n\nAgain \"git pull origin\" gives the same errors.\n\nSo I went into .git/remotes/origin and\nremoved the lines pointing at these branches and removed the gb and jc\ndirectories\nand did another git pull and it seems to have worked.\n\nI would suggest that when the pull detects the missing remote ref, it\nshould clean\nup the remotes/origin file. Or have I done entirely the wrong thing?\n\nCheers,\nGeoff Russell.\n"},{"id":"21572","messageId":"7v1wtwh246.fsf@assigned-by-dhcp.cox.net","threadId":"4457","inReplyTo":"93c3eada0606101707t5eb35a4du3ebd0fd17737943f@mail.gmail.com","subject":"Re: Problem upgrading to 1.4.0","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-11T02:12:25Z","receivedAt":"2006-06-11T02:12:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Geoff Russell\" writes:\n\n> Hi,\n>\n> When I do a \"git pull origin\" I get messages:\n>\n> error: no such remote ref refs/heads/gb/diffdelta\n> error: no such remote ref refs/heads/jc/bind\n> error: no such remote ref refs/heads/jc/bind-2\n> ...\n> Fetch failure: git://git.kernel.org/pub/scm/git/git.git\n>...\n> So I went into .git/remotes/origin and\n> removed the lines pointing at these branches and removed the gb and jc\n> directories\n> and did another git pull and it seems to have worked.\n\nThis is the second time this same gotcha caused trouble here. I\nagree it would be sensible to make git-fetch (which is called by\ngit-pull) to detect stale entries in the remotes/origin file and\nremote.origin.fetch configuration items.\n"},{"id":"21696","messageId":"1150165982.4297.88.camel@dv","threadId":"4457","inReplyTo":"7v1wtwh246.fsf@assigned-by-dhcp.cox.net","subject":"Re: Problem upgrading to 1.4.0","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-06-13T02:33:02Z","receivedAt":"2006-06-13T02:33:02Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Sat, 2006-06-10 at 19:12 -0700, Junio C Hamano wrote:\n\n> This is the second time this same gotcha caused trouble here. I\n> agree it would be sensible to make git-fetch (which is called by\n> git-pull) to detect stale entries in the remotes/origin file and\n> remote.origin.fetch configuration items.\n\nAnd while at that, it would be great to download and keep the list of\nthe remote branches, perhaps when requested with a special switch. It\ndoesn't mean that all of the branches should be fetched, but it would be\nnice to have a list of the available remove branches somewhere.\n\nAs it stands now, this functionality is implemented in git-clone, which\nit probably not the best place. Users should not be forced to clone the\ndirectory again to find out which branches are available.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"21697","messageId":"BAYC1-PASMTP057F6CD43B793C898A6952AE8C0@CEZ.ICE","threadId":"4457","inReplyTo":"1150165982.4297.88.camel@dv","subject":"Re: Problem upgrading to 1.4.0","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-06-13T02:48:18Z","receivedAt":"2006-06-13T02:48:18Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Mon, 12 Jun 2006 22:33:02 -0400\nPavel Roskin wrote:\n\n> And while at that, it would be great to download and keep the list of\n> the remote branches, perhaps when requested with a special switch. It\n> doesn't mean that all of the branches should be fetched, but it would be\n> nice to have a list of the available remove branches somewhere.\n> \n> As it stands now, this functionality is implemented in git-clone, which\n> it probably not the best place. Users should not be forced to clone the\n> directory again to find out which branches are available.\n\nHi Pavel,\n\nYou can get a list of the remote branches whenever you want:\n\n$ git ls-remote -h \n\nSo, to see available branches in the repo from which you initially\ncloned:\n\n$ git ls-remote -h origin\n\nOr to see which branches are available in the official cogito repo,\nwithout ever cloning it:\n\n$ git ls-remote -h git://git.kernel.org/pub/scm/cogito/cogito.git\n\nHTH,\nSean\n"},{"id":"21698","messageId":"1150167759.4297.95.camel@dv","threadId":"4457","inReplyTo":"20060612224818.383b13ee.seanlkml@sympatico.ca","subject":"Re: Problem upgrading to 1.4.0","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-06-13T03:02:39Z","receivedAt":"2006-06-13T03:02:39Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hi, Sean!\n\nOn Mon, 2006-06-12 at 22:48 -0400, Sean wrote:\n> Hi Pavel,\n> \n> You can get a list of the remote branches whenever you want:\n> \n> $ git ls-remote -h \n\nI heard of that command. But git-clone only uses it for local and rsync\nprotocols. If it's so good, shouldn't it be used unconditionally or at\nleast with minimal exceptions (some kinds of local clones)?\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"21700","messageId":"Pine.LNX.4.64.0606122024400.5498@g5.osdl.org","threadId":"4457","inReplyTo":"1150167759.4297.95.camel@dv","subject":"Re: Problem upgrading to 1.4.0","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-13T03:28:52Z","receivedAt":"2006-06-13T03:28:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 12 Jun 2006, Pavel Roskin wrote:\n>\n> > You can get a list of the remote branches whenever you want:\n> > \n> > $ git ls-remote -h \n> \n> I heard of that command. But git-clone only uses it for local and rsync\n> protocols.\n\nThe native format doesn't _need_ to use \"git ls-remote\", because the \nnative format does it on its own.\n\nIn fact, \"git ls-remote\" actually uses the pack transfer protocol to \nfigure out what the remote heads are (it just then doesn't _ask_ for \nanything), so in many ways you can see \"git ls-remote\" as being just a \nhelper around the basic clone/pull protocol.\n\nSo \"git clone\" ends up doing the equivalent of a git ls-remote to populate \nthe initial local heads and tags. It's just that for the native protocol, \nit all happens together in one burst.\n\n\t\tLinus\n"},{"id":"21702","messageId":"1150170985.4297.104.camel@dv","threadId":"4457","inReplyTo":"Pine.LNX.4.64.0606122024400.5498@g5.osdl.org","subject":"Re: Problem upgrading to 1.4.0","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-06-13T03:56:25Z","receivedAt":"2006-06-13T03:56:25Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Mon, 2006-06-12 at 20:28 -0700, Linus Torvalds wrote:\n> \n> On Mon, 12 Jun 2006, Pavel Roskin wrote:\n> >\n> > > You can get a list of the remote branches whenever you want:\n> > > \n> > > $ git ls-remote -h \n> > \n> > I heard of that command. But git-clone only uses it for local and rsync\n> > protocols.\n> \n> The native format doesn't _need_ to use \"git ls-remote\", because the \n> native format does it on its own.\n\nOK. I actually suspected that git-ls-remote was limited to some\nprotocols. I'm glad to be wrong about it.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"21712","messageId":"93c3eada0606130010q350f2412w714134ca621608b2@mail.gmail.com","threadId":"4457","inReplyTo":"1150170985.4297.104.camel@dv","subject":"Re: Problem upgrading to 1.4.0","fromName":"Geoff Russell","fromEmail":"geoffrey.russell@gmail.com","sentAt":"2006-06-13T07:10:31Z","receivedAt":"2006-06-13T07:10:31Z","isPatch":false,"sender":{"key":"geoffrey.russell@gmail.com","avatar":"https://gravatar.com/avatar/c30f497ccfa6bf06d86f30bd2ba092a2dd124c61c6bc902f7cb5c3f6486947de?d=mp&s=160"},"body":"On 6/13/06, Pavel Roskin wrote:\n> On Mon, 2006-06-12 at 20:28 -0700, Linus Torvalds wrote:\n> >\n> > On Mon, 12 Jun 2006, Pavel Roskin wrote:\n> > >\n> > > > You can get a list of the remote branches whenever you want:\n> > > >\n> > > > $ git ls-remote -h \n> > >\n> > > I heard of that command. But git-clone only uses it for local and rsync\n> > > protocols.\n> >\n> > The native format doesn't _need_ to use \"git ls-remote\", because the\n> > native format does it on its own.\n>\n> OK. I actually suspected that git-ls-remote was limited to some\n> protocols. I'm glad to be wrong about it.\n\nJust so we don't lose sight of the forest for the trees, the most\ncommon thing I want to do is: \"get me up-to-date-with-origin,\ndon't overwrite any branches of mine, but get me anything on the\norigin which I don't have\". Hence I think this should be one fairly\nsimple command -- git pull origin.\n\nThe first time I had this problem, I gave up trying to fix it and just\nrm'd my git\nrepository and re'cloned it. The second time it happened, I knew a\nlittle bit more and worked out how to fix it.\n\nCheers,\nGeoff Russell\n\n\n\n>\n> --\n> Regards,\n> Pavel Roskin\n>\n>\n"}]}