Mike Hommey <mh@xxxxxxxxxxxx> writes: > A typical remote helper will return a `list` of refs containing a symbolic > ref HEAD, pointing to, e.g. refs/heads/master. In the case of a clone, all > the refs are being requested through `fetch` or `import`, including the > symbolic ref. > > While this works properly, in some cases of a fetch, like `git fetch url` > or `git fetch origin HEAD`, or any fetch command involving a symbolic ref > without also fetching the corresponding ref it points to, the fetch command > fails with: > > fatal: bad object 0000000000000000000000000000000000000000 > error: <remote> did not send all necessary objects > > (in the case the remote helper returned '?' values to the `list` command). Hmph. Since the most "typical remote helper" I immediately think of is remote-curl and "git fetch https://code.googlesource.com/git HEAD" does not seem to fail that way, I am not sure what to make of the above. It is unclear if you meant that the above is inherent due to the way how remote helper protocol works (e.g. there is only one thing we can associate with a ref and we cannot say "HEAD points at this commit" at the same time we say "HEAD points at refs/heads/master"), or just due to broken or lazy implementation of the remote helpers that are invoked by transport-helper.c interface. > This is because there is only one ref given to fetch(), and it's not > further resolved to something at the end of fetch_with_import(). There is no get_refs_list() or something similar involved? -- 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