I'm frequently needing to get code from a git repository onto a server where it will be run. The short way - but high bandwidth and non-ideal security - is just to clone the entire repo. Better would be to simply copy out the current state of the code.
In an existing git repo you can create a tar file of the current state of the code:
$ git archive --format=tar HEAD | gzip > test.tar.gz $
This returns silently (and successfully). But attempt it remotely against github and it fails:
$ git archive --firstname.lastname@example.org:tpl-eservices/kids-under-five.git --format=tar HEAD | gzip > test.tar.gz Invalid command: 'git-upload-archive 'tpl-eservices/kids-under-five.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
But if I run a nearly identical request against my own git host:
$ git archive --remote='git@gitbox:~/vim.git' --format=tar HEAD | gzip > test.tar.gz $
it silently executes exactly as it should, producing a gzipped tarball. So what's going on here??
Q: Can I archive a repository? A: GitHub does not provide archiving. ...
There's more content there, but the only alternative they suggest is "clone the archive." Great, that's what I was trying to avoid. And that's weird, because the site presents an alternative: under "clone or download", one of the options is to "Download ZIP", which does almost exactly what I wanted - although with significant limitations:
- only the current HEAD is available, you can't get older revs (I'm okay with this)
- only Zip compression, not tarballs or other packing methods that git archive provides (I'm mostly okay with this)
- the URL doesn't seem to be programmatically accessible, ie. you click on it, it works, you copy the URL and try to use curl and it doesn't work (it's an authentication issue - I'm not okay with the "solution" they offer)
Github provides a simple solution for this if the repo is public:
$ curl -L https://github.com/gilesorr/gitcheck/tarball/master > gitcheck.head.tar
"-L" is needed because the first returned data is a redirect, and curl would otherwise display that. This switch makes it follow the redirect.
But if the repo is private, this gets ugly with the need for OAuth2 tokens (links in Bibliography) ... whereas if they'd supported git archive over ssh, none of this complexity would be needed as you'd be using the same command (git) you've been using all along ... I really don't need another authentication method when I have no other use for it: this is a real PITA and a significant black mark on github's record as far as I'm concerned.
I've filed a support request with github asking if they intend to support git archive. I'm expecting an answer in the negative, we'll see.
Thanks for your feedback! We can't say if/when we may add a feature. By not publicly announcing upcoming features, we change direction at the last minute on a potential feature without causing disappointment. This can be frustrating at times, but I hope you can understand why it's necessary.
What I can do is add a +1 for you to adding support for git archive on our feature request list.
If you have any questions or more feedback, please feel free to get in touch.