Problem upgrading to 1.4.0

Problem upgrading to 1.4.0

[Geoff Russell]

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.

Re: Problem upgrading to 1.4.0

[Junio C Hamano]

"Geoff Russell" <geoffrey.russell@gmail.com> 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.

Re: Problem upgrading to 1.4.0

[Pavel Roskin]

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

Re: Problem upgrading to 1.4.0

[Sean]

On Mon, 12 Jun 2006 22:33:02 -0400
Pavel Roskin <proski@gnu.org> 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 <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

Re: Problem upgrading to 1.4.0

[Pavel Roskin]

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 <remote>

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

Re: Problem upgrading to 1.4.0

[Linus Torvalds]

On Mon, 12 Jun 2006, Pavel Roskin wrote:
>
> > You can get a list of the remote branches whenever you want:
> > 
> > $ git ls-remote -h <remote>
> 
> 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

Re: Problem upgrading to 1.4.0

[Pavel Roskin]

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 <remote>
> > 
> > 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

Re: Problem upgrading to 1.4.0

[Geoff Russell]

On 6/13/06, Pavel Roskin <proski@gnu.org> 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 <remote>
> > >
> > > 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
>
>