Can't get 'git archive' to work

Can't get 'git archive' to work

[Yuri]

Getting the errors, see below.

Why "operation is not supported" through http and https? 'archive' is 
supposed to be the most efficient operation to get the specific snapshot 
of the repository, and it should be available without authentication.

In case of ssh with the key there is the strange error message about 
"core.gitProxy". What is this about? I am not using a proxy.

I couldn't get git archive to work even once.

# through ssh with an active ssh key
$ git archive --format=tar --remote=git@github.com:yurivict/vm-to-tor.git
Invalid command: 'git-upload-archive 'yurivict/vm-to-tor.git''
   You appear to be using ssh to clone a git:// URL.
   Make sure your core.gitProxy config option and the
   GIT_PROXY_COMMAND environment variable are NOT set.
fatal: The remote end hung up unexpectedly

# through ssh without an ssh key
$  git archive --format=tar --remote=git@github.com:yurivict/vm-to-tor.git
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

# through https
$  git archive --format=tar 
--remote=https://github.com/yurivict/vm-to-tor.git
fatal: Operation not supported by protocol.

# through http
$  git archive --format=tar 
--remote=http://github.com/yurivict/vm-to-tor.git
fatal: Operation not supported by protocol.


git-2.6.2 on FreeBSD 10.2

Yuri

Re: Can't get 'git archive' to work

[Jeff King]

On Sun, Dec 06, 2015 at 09:31:06PM -0800, Yuri wrote:

> Why "operation is not supported" through http and https? 'archive' is
> supposed to be the most efficient operation to get the specific snapshot of
> the repository, and it should be available without authentication.

Remote git-archive is not well-supported. It does work over git-daemon,
but the server side has to explicitly turn it on in their config. It was
never plumbed into the git-over-http protocol at all. ssh is generally
the only place it works out-of-the-box (but see below).

> In case of ssh with the key there is the strange error message about
> "core.gitProxy". What is this about? I am not using a proxy.
> [...]
> # through ssh with an active ssh key
> $ git archive --format=tar --remote=git@github.com:yurivict/vm-to-tor.git
> Invalid command: 'git-upload-archive 'yurivict/vm-to-tor.git''
>   You appear to be using ssh to clone a git:// URL.
>   Make sure your core.gitProxy config option and the
>   GIT_PROXY_COMMAND environment variable are NOT set.
> fatal: The remote end hung up unexpectedly

This message isn't from git, but rather from GitHub's ssh server. You
can see it here without running git locally at all:

  $ ssh git@github.com git-upload-archive
  Invalid command: 'git-upload-archive'
  You appear to be using ssh to clone a git:// URL.
  Make sure your core.gitProxy config option and the
  GIT_PROXY_COMMAND environment variable are NOT set.

The short of it is that GitHub does not support remote git-archive at
all, not even over ssh. Part of the reason is that it maintains a
separate caching layer for grabbing zips and tarballs, which is
available at an http endpoint:

  https://github.com/yurivict/vm-to-tor/archive/master.tar.gz

Clearly the advice above is not helpful in this case; I don't recall the
case that it was originally written to help. You may want to write to
GitHub support about it.

> # through ssh without an ssh key
> $  git archive --format=tar --remote=git@github.com:yurivict/vm-to-tor.git
> Permission denied (publickey).
> fatal: The remote end hung up unexpectedly

GitHub's ssh server only accepts key authentication, so this is not
surprising.

> # through https
> $  git archive --format=tar
> --remote=https://github.com/yurivict/vm-to-tor.git
> fatal: Operation not supported by protocol.
> 
> # through http
> $  git archive --format=tar
> --remote=http://github.com/yurivict/vm-to-tor.git
> fatal: Operation not supported by protocol.

This comes from the local git client. There's no scheme defined for
hitting git-upload-archive (the server side of a remote git-archive)
over HTTP. You'd have to define it, implement the client side of it, and
then convince the server side to configure their HTTP servers to handle
it as a CGI. That might be a nice project to work on, but it will not
get you tarballs anytime soon. :)

-Peff