On Wed, Jan 21, 2015 at 10:46:48PM -0800, Junio C Hamano wrote: > 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. Note the most important part is actually between the parens: that only happens when the remote helper returns '?' to the `list` command, which non-git remotes helpers (like git-remote-hg or git-remote-bzr) do. git-remote-testgit also does, so if you only apply the test parts of the patch, you'll see that the test fails. remote-curl probably doesn't hit the problem because it's not returning '?' to `list`. Mike -- 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