Problem upgrading to 1.4.0

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.

"Geoff Russell" <geoffrey.russell@gmail.com> writes:

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.

On Sat, 2006-06-10 at 19:12 -0700, Junio C Hamano 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.

On Mon, 12 Jun 2006 22:33:02 -0400 Pavel Roskin <proski@gnu.org> wrote:

Hi Pavel,

You can get a list of the remote branches whenever you want:

$ git ls-remote -h <remote>

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

Hi, Sean!

On Mon, 2006-06-12 at 22:48 -0400, Sean wrote:

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)?

On Mon, 12 Jun 2006, Pavel Roskin wrote:

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

On Mon, 2006-06-12 at 20:28 -0700, Linus Torvalds wrote:

OK. I actually suspected that git-ls-remote was limited to some protocols. I'm glad to be wrong about it.

On 6/13/06, Pavel Roskin <proski@gnu.org> wrote:

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