Sometimes "Failed to find remote refs" means "try git-fetch --no-tags"

Sometimes "Failed to find remote refs" means "try git-fetch --no-tags"

[Michael K. Edwards]

Down inside git-ls-remote there is a die "Failed to find remote refs".
 This struck when I tried to fetch an http repository with a missing
info/refs file.  Using "git fetch --no-tags" succeeds because it
doesn't have to call git-ls-remote at all.  Does git-ls-remote have
any way of knowing who is calling it so that it can print a
context-appropriate error message?  If not, is it worth adding some
sort of "caller context" mechanism, perhaps at the boundary between
porcelain and plumbing?  Or should the error message include, "If you
were trying to do a 'git fetch', try --no-tags; you won't get tags but
you may get a good update of the branch content"?

Cheers,

Re: Sometimes "Failed to find remote refs" means "try git-fetch --no-tags"

[Junio C Hamano]

"Michael K. Edwards" <medwards.linux@gmail.com> writes:

> Down inside git-ls-remote there is a die "Failed to find remote refs".
> This struck when I tried to fetch an http repository with a missing
> info/refs file.  Using "git fetch --no-tags" succeeds because it
> doesn't have to call git-ls-remote at all.  Does git-ls-remote have
> any way of knowing who is calling it so that it can print a
> context-appropriate error message?  If not, is it worth adding some
> sort of "caller context" mechanism, perhaps at the boundary between
> porcelain and plumbing?

I think letting git-ls-remote know who called it makes sense for
better error reporting.  I am all for it.

However "fetch --no-tags" from http upstream is a band-aid to
hide that the upstream repository has stale info/refs, and I do
not think we would want to encourage the band-aid.  Rather, the
message should say "yell loudly at the repository owner" ;-).

Seriously, when people starts using packed-refs that will be in
v1.4.4 scheduled for tomorrow on the public site, I think the
best way to adjust the commit walker clients is to have them
download info/refs and start traversing from the objects listed
there, instead of downloading .git/refs/heads/$branch and
.git/refs/tags/$tag files as we currently do, so the band-aid
would become less useful.

Re: Sometimes "Failed to find remote refs" means "try git-fetch --no-tags"

[Horst H. von Brand]

Junio C Hamano <junkio@cox.net> wrote:

[...]

> However "fetch --no-tags" from http upstream is a band-aid to
> hide that the upstream repository has stale info/refs, and I do
> not think we would want to encourage the band-aid.  Rather, the
> message should say "yell loudly at the repository owner" ;-).

I'm seeing this gem here:

  [vonbrand@laptop13 git]$ git pull
  fatal: read error (Connection reset by peer)
  Fetch failure: git://git.kernel.org/pub/scm/git/git.git
  fatal: read error (Connection reset by peer)
  Failed to find remote refs
  No changes.

Who shall I yell at? ;-)

Seriously, this is broken. I get 4 different error messages, plus a
(reassuring?) "No changes". Yes, I know this is what I'll see if the
machine is overloaded.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239