Re: [PATCH] transport-helper: do not request symbolic refs to remote helpers

[Junio C Hamano <gitster@pobox.com>]

Mike Hommey <mh@glandium.org> 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?