# Problem upgrading to 1.4.0 8 messages from 2006-06-11 to 2006-06-13. Participants: Geoff Russell, Junio C Hamano, Pavel Roskin, Sean, Linus Torvalds. Thread: https://gitlist.dev/t/4457 ## Geoff Russell, 2006-06-11 00:07 Subject: Problem upgrading to 1.4.0 Message-ID: <93c3eada0606101707t5eb35a4du3ebd0fd17737943f@mail.gmail.com> URL: https://gitlist.dev/e/93c3eada0606101707t5eb35a4du3ebd0fd17737943f%40mail.gmail.com ``` Hi, When I do a "git pull origin" I get messages: error: no such remote ref refs/heads/gb/diffdelta error: no such remote ref refs/heads/jc/bind error: no such remote ref refs/heads/jc/bind-2 ... Fetch failure: git://git.kernel.org/pub/scm/git/git.git So I figured these branches were "in the way" so I deleted them: git branch -D gb/diffdelta etc. Again "git pull origin" gives the same errors. So I went into .git/remotes/origin and removed the lines pointing at these branches and removed the gb and jc directories and did another git pull and it seems to have worked. I would suggest that when the pull detects the missing remote ref, it should clean up the remotes/origin file. Or have I done entirely the wrong thing? Cheers, Geoff Russell. ``` ## Junio C Hamano, 2006-06-11 02:12 Subject: Re: Problem upgrading to 1.4.0 Message-ID: <7v1wtwh246.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v1wtwh246.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <93c3eada0606101707t5eb35a4du3ebd0fd17737943f@mail.gmail.com> ``` "Geoff Russell" writes: > Hi, > > When I do a "git pull origin" I get messages: > > error: no such remote ref refs/heads/gb/diffdelta > error: no such remote ref refs/heads/jc/bind > error: no such remote ref refs/heads/jc/bind-2 > ... > Fetch failure: git://git.kernel.org/pub/scm/git/git.git >... > So I went into .git/remotes/origin and > removed the lines pointing at these branches and removed the gb and jc > directories > and did another git pull and it seems to have worked. This is the second time this same gotcha caused trouble here. I agree it would be sensible to make git-fetch (which is called by git-pull) to detect stale entries in the remotes/origin file and remote.origin.fetch configuration items. ``` ## Pavel Roskin, 2006-06-13 02:33 Subject: Re: Problem upgrading to 1.4.0 Message-ID: <1150165982.4297.88.camel@dv> URL: https://gitlist.dev/e/1150165982.4297.88.camel%40dv In-Reply-To: <7v1wtwh246.fsf@assigned-by-dhcp.cox.net> ``` On Sat, 2006-06-10 at 19:12 -0700, Junio C Hamano wrote: > This is the second time this same gotcha caused trouble here. I > agree it would be sensible to make git-fetch (which is called by > git-pull) to detect stale entries in the remotes/origin file and > remote.origin.fetch configuration items. And while at that, it would be great to download and keep the list of the remote branches, perhaps when requested with a special switch. It doesn't mean that all of the branches should be fetched, but it would be nice to have a list of the available remove branches somewhere. As it stands now, this functionality is implemented in git-clone, which it probably not the best place. Users should not be forced to clone the directory again to find out which branches are available. -- Regards, Pavel Roskin ``` ## Sean, 2006-06-13 02:48 Subject: Re: Problem upgrading to 1.4.0 Message-ID: URL: https://gitlist.dev/e/BAYC1-PASMTP057F6CD43B793C898A6952AE8C0%40CEZ.ICE In-Reply-To: <1150165982.4297.88.camel@dv> ``` On Mon, 12 Jun 2006 22:33:02 -0400 Pavel Roskin wrote: > And while at that, it would be great to download and keep the list of > the remote branches, perhaps when requested with a special switch. It > doesn't mean that all of the branches should be fetched, but it would be > nice to have a list of the available remove branches somewhere. > > As it stands now, this functionality is implemented in git-clone, which > it probably not the best place. Users should not be forced to clone the > directory again to find out which branches are available. Hi Pavel, You can get a list of the remote branches whenever you want: $ git ls-remote -h So, to see available branches in the repo from which you initially cloned: $ git ls-remote -h origin Or to see which branches are available in the official cogito repo, without ever cloning it: $ git ls-remote -h git://git.kernel.org/pub/scm/cogito/cogito.git HTH, Sean ``` ## Pavel Roskin, 2006-06-13 03:02 Subject: Re: Problem upgrading to 1.4.0 Message-ID: <1150167759.4297.95.camel@dv> URL: https://gitlist.dev/e/1150167759.4297.95.camel%40dv In-Reply-To: <20060612224818.383b13ee.seanlkml@sympatico.ca> ``` Hi, Sean! On Mon, 2006-06-12 at 22:48 -0400, Sean wrote: > Hi Pavel, > > You can get a list of the remote branches whenever you want: > > $ git ls-remote -h I heard of that command. But git-clone only uses it for local and rsync protocols. If it's so good, shouldn't it be used unconditionally or at least with minimal exceptions (some kinds of local clones)? -- Regards, Pavel Roskin ``` ## Linus Torvalds, 2006-06-13 03:28 Subject: Re: Problem upgrading to 1.4.0 Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0606122024400.5498%40g5.osdl.org In-Reply-To: <1150167759.4297.95.camel@dv> ``` On Mon, 12 Jun 2006, Pavel Roskin wrote: > > > You can get a list of the remote branches whenever you want: > > > > $ git ls-remote -h > > I heard of that command. But git-clone only uses it for local and rsync > protocols. The native format doesn't _need_ to use "git ls-remote", because the native format does it on its own. In fact, "git ls-remote" actually uses the pack transfer protocol to figure out what the remote heads are (it just then doesn't _ask_ for anything), so in many ways you can see "git ls-remote" as being just a helper around the basic clone/pull protocol. So "git clone" ends up doing the equivalent of a git ls-remote to populate the initial local heads and tags. It's just that for the native protocol, it all happens together in one burst. Linus ``` ## Pavel Roskin, 2006-06-13 03:56 Subject: Re: Problem upgrading to 1.4.0 Message-ID: <1150170985.4297.104.camel@dv> URL: https://gitlist.dev/e/1150170985.4297.104.camel%40dv In-Reply-To: ``` On Mon, 2006-06-12 at 20:28 -0700, Linus Torvalds wrote: > > On Mon, 12 Jun 2006, Pavel Roskin wrote: > > > > > You can get a list of the remote branches whenever you want: > > > > > > $ git ls-remote -h > > > > I heard of that command. But git-clone only uses it for local and rsync > > protocols. > > The native format doesn't _need_ to use "git ls-remote", because the > native format does it on its own. OK. I actually suspected that git-ls-remote was limited to some protocols. I'm glad to be wrong about it. -- Regards, Pavel Roskin ``` ## Geoff Russell, 2006-06-13 07:10 Subject: Re: Problem upgrading to 1.4.0 Message-ID: <93c3eada0606130010q350f2412w714134ca621608b2@mail.gmail.com> URL: https://gitlist.dev/e/93c3eada0606130010q350f2412w714134ca621608b2%40mail.gmail.com In-Reply-To: <1150170985.4297.104.camel@dv> ``` On 6/13/06, Pavel Roskin wrote: > On Mon, 2006-06-12 at 20:28 -0700, Linus Torvalds wrote: > > > > On Mon, 12 Jun 2006, Pavel Roskin wrote: > > > > > > > You can get a list of the remote branches whenever you want: > > > > > > > > $ git ls-remote -h > > > > > > I heard of that command. But git-clone only uses it for local and rsync > > > protocols. > > > > The native format doesn't _need_ to use "git ls-remote", because the > > native format does it on its own. > > OK. I actually suspected that git-ls-remote was limited to some > protocols. I'm glad to be wrong about it. Just so we don't lose sight of the forest for the trees, the most common thing I want to do is: "get me up-to-date-with-origin, don't overwrite any branches of mine, but get me anything on the origin which I don't have". Hence I think this should be one fairly simple command -- git pull origin. The first time I had this problem, I gave up trying to fix it and just rm'd my git repository and re'cloned it. The second time it happened, I knew a little bit more and worked out how to fix it. Cheers, Geoff Russell > > -- > Regards, > Pavel Roskin > > ```