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

2 messages from 2006-11-15 to 2006-11-15. Participants: Junio C Hamano, Michael K. Edwards.
Thread: https://gitlist.dev/t/43465

## Michael K. Edwards, 2006-11-15 03:53

Subject: Sometimes "Failed to find remote refs" means "try git-fetch --no-tags"
Message-ID: <f2b55d220611141953t48d81ac5q4f48183ae79ba0a@mail.gmail.com>
URL: https://gitlist.dev/e/f2b55d220611141953t48d81ac5q4f48183ae79ba0a%40mail.gmail.com

```
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,

```

## Junio C Hamano, 2006-11-15 04:05

Subject: Re: Sometimes "Failed to find remote refs" means "try git-fetch --no-tags"
Message-ID: <7vvelhs6bw.fsf@assigned-by-dhcp.cox.net>
URL: https://gitlist.dev/e/7vvelhs6bw.fsf%40assigned-by-dhcp.cox.net
In-Reply-To: <f2b55d220611141953t48d81ac5q4f48183ae79ba0a@mail.gmail.com>

```
"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.


```