1

When I try to run git archive on a local repository from a different directory

git archive --format=tar.gz --remote=file:///home/user/repos/repodir --prefix=/tmp/test_archive -o archive.tar.gz ref12345

this command fails with the output below. It seems the remote option is not accepted.

remote: fatal: no such ref: ref12345
fatal: sent error to the client: git upload-archive: archiver died with error
remote: git upload-archive: archiver died with error

When I switch to the repo directory and execute without the remote option it is fine. ie

cd /home/user/repos/repodir
git archive --format=tar.gz  --prefix=/tmp/test_archive -o archive.tar.gz ref12345

Is there a flaw in the --remote syntax used, or is the --remote option not supported for local repositories?

Kara
  • 6,115
  • 16
  • 50
  • 57
vfclists
  • 19,193
  • 21
  • 73
  • 92
  • What version of git are you using? I'm using 2.3.1 and it works fine using `--remote=file://...` and `--remote=/path/to/repo`. The error message seems to indicate something wrong with the ref. I tried running it outside a git repo, and inside another unrelated repo requesting a tag that didn't exist in the current repo, and it all worked as expected. – John Szakmeister Mar 07 '15 at 10:48
  • My git version is `1.9.1` it is the distribution's default version, Trusty Tahr – vfclists Mar 07 '15 at 11:32
  • Interesting. I wonder if something wasn't spelled correctly when you tried this. I don't see any bug fixes involving archive between your version and mine. :-( All of that aside, git does support using `git archive` with file:// urls and /paths. – John Szakmeister Mar 07 '15 at 12:29
  • Isn't the SHA alone a valid treeish, or do I have to specify a branch as well? The Git repo is a mirror of a main repo, which is refreshed for compiling and the default branch is the upstream. Could it be possible that it could be the problem. I think so long as the ref appears in the the git log it should be available for `git archive` or am I missing some key git concepts – vfclists Mar 10 '15 at 16:08
  • Yes, the SHA1 of the commit is a valid treeish. You didn't say that's what you are using though. I assume that the output you have above was modified, so I can't really tell what is going on. But a simple misspelling could have been the issue. Either way, what you want to do is supported, so it was either user error, or something weird is happening with you repository. – John Szakmeister Mar 10 '15 at 17:18
  • Is it possible that the ref refers to a commit which is not available locally? Does a mirror differ from a normal repo? – vfclists Mar 10 '15 at 20:20

1 Answers1

0

This is an old question, but I was seeing the same problem and came here while searching for a solution.

This is actually a side-effect of security controls implemented in git-upload-archive, which is invoked by git archive --remote. From the Security section of the docs for git-upload-archive:

Clients may not use other sha1 expressions, even if the end result is reachable. E.g., neither a relative commit like master^ nor a literal sha1 like abcd1234 is allowed, even if the result is reachable from the refs.

There is an option described to disable this behaviour:

If the config option uploadArchive.allowUnreachable is true, these rules are ignored, and clients may use arbitrary sha1 expressions. This is useful if you do not care about the privacy of unreachable objects, or if your object database is already publicly available for access via non-smart-http.

However if you are able to run the command locally, it is maybe simpler, as OP found, to avoid the issue entirely by executing the git archive command from the repository directory. I ended up doing this, similar to one of the examples in the git archive docs:

cd $REPO && git archive --format=tar $SHA1 | (cd $TARGET_DIR && tar xf -)

I came across this solution in this Gitea issue. Other related questions here on SO:

Don't Panic
  • 13,965
  • 5
  • 32
  • 51