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

[Mike Hommey <mh@glandium.org>]

On Wed, Jan 21, 2015 at 10:46:48PM -0800, Junio C Hamano wrote:
> 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.

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