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

Michael K. Edwards· Nov 15, 2006, 03:53 UTC · lore

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

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· Nov 15, 2006, 04:05 UTC · re: Michael K. Edwards · lore

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