{"thread":{"id":"43465","subject":"Re: Sometimes \"Failed to find remote refs\" means \"try git-fetch --no-tags\"","startedAt":"2006-11-15T03:53:34Z","lastAt":"2006-11-15T04:05:07Z","messageCount":2,"participants":["Junio C Hamano","Michael K. Edwards"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"296217","messageId":"f2b55d220611141953t48d81ac5q4f48183ae79ba0a@mail.gmail.com","threadId":"43465","inReplyTo":null,"subject":"Sometimes \"Failed to find remote refs\" means \"try git-fetch --no-tags\"","fromName":"Michael K. Edwards","fromEmail":"medwards.linux@gmail.com","sentAt":"2006-11-15T03:53:34Z","receivedAt":"2006-11-15T03:53:34Z","isPatch":false,"sender":{"key":"medwards.linux@gmail.com","avatar":null},"body":"Down inside git-ls-remote there is a die \"Failed to find remote refs\".\n This struck when I tried to fetch an http repository with a missing\ninfo/refs file.  Using \"git fetch --no-tags\" succeeds because it\ndoesn't have to call git-ls-remote at all.  Does git-ls-remote have\nany way of knowing who is calling it so that it can print a\ncontext-appropriate error message?  If not, is it worth adding some\nsort of \"caller context\" mechanism, perhaps at the boundary between\nporcelain and plumbing?  Or should the error message include, \"If you\nwere trying to do a 'git fetch', try --no-tags; you won't get tags but\nyou may get a good update of the branch content\"?\n\nCheers,\n"},{"id":"294930","messageId":"7vvelhs6bw.fsf@assigned-by-dhcp.cox.net","threadId":"43465","inReplyTo":"f2b55d220611141953t48d81ac5q4f48183ae79ba0a@mail.gmail.com","subject":"Re: Sometimes \"Failed to find remote refs\" means \"try git-fetch --no-tags\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T04:05:07Z","receivedAt":"2006-11-15T04:05:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael K. Edwards\" <medwards.linux@gmail.com> writes:\n\n> Down inside git-ls-remote there is a die \"Failed to find remote refs\".\n> This struck when I tried to fetch an http repository with a missing\n> info/refs file.  Using \"git fetch --no-tags\" succeeds because it\n> doesn't have to call git-ls-remote at all.  Does git-ls-remote have\n> any way of knowing who is calling it so that it can print a\n> context-appropriate error message?  If not, is it worth adding some\n> sort of \"caller context\" mechanism, perhaps at the boundary between\n> porcelain and plumbing?\n\nI think letting git-ls-remote know who called it makes sense for\nbetter error reporting.  I am all for it.\n\nHowever \"fetch --no-tags\" from http upstream is a band-aid to\nhide that the upstream repository has stale info/refs, and I do\nnot think we would want to encourage the band-aid.  Rather, the\nmessage should say \"yell loudly at the repository owner\" ;-).\n\nSeriously, when people starts using packed-refs that will be in\nv1.4.4 scheduled for tomorrow on the public site, I think the\nbest way to adjust the commit walker clients is to have them\ndownload info/refs and start traversing from the objects listed\nthere, instead of downloading .git/refs/heads/$branch and\n.git/refs/tags/$tag files as we currently do, so the band-aid\nwould become less useful.\n\n"}]}