"Michael K. Edwards" <medwards.linux@xxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html