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

From: Junio C Hamano <junkio@cox.net>
Date: Nov 15, 2006, 04:05 UTC
Message-ID: <7vvelhs6bw.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <f2b55d220611141953t48d81ac5q4f48183ae79ba0a@mail.gmail.com>

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

Show 8 quoted lines

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