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

"Michael K. Edwards" [off-list ref] 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.