transport-helper: do not request symbolic refs to remote helpers
commit33cae5428ab504e318cfac880d59e0bda58590d7
authorMike Hommey <mh@glandium.org>
Mon, 19 Jan 2015 01:35:07 +0000 (19 10:35 +0900)
committerJunio C Hamano <gitster@pobox.com>
Thu, 22 Jan 2015 06:46:59 +0000 (21 22:46 -0800)
tree5cfe024a40a57248141c4524c47bea043ae885d8
parent627736ca799edacf13881da7e671964a0afb94b8
transport-helper: do not request symbolic refs to remote helpers

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

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().

While this can be somehow handled in the remote helper itself, by adding
a refspec for the symbolic ref, and storing an explicit ref in a private
namespace, and then handling the `import` for that symbolic ref
specifically, very few existing remote helpers are actually doing that.

So, instead of requesting the exact list of wanted refs to remote helpers,
treat symbolic refs differently and request the ref they point to instead.
Then, resolve the symbolic refs values based on the pointed ref.
This assumes there is no more than one level of indirection (a symbolic
ref doesn't point to another symbolic ref).

Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote-testgit.sh
t/t5801-remote-helpers.sh
transport-helper.c