CC me on answers please, since I'm not subscribed to the list
Hello,
I would like to ask a question about commit restriction added to git
archive by commit (ee27ca4a: archive: don't let remote clients get
unreachable commits, 2011-11-17) and following efforts to loosen them
a bit.
In out company we are using git together with source indexing. We
store a git command for retrieval of source code file that was used
for building into pdb file(s). Currently, we are using an invocation
of git archive with --remote parameter and commit sha1 to export
exactly the source code that was used for build.
The above mentioned commit removed possibility to do that. I have read
about efforts to loosen the restrictions,
but I'm not sure whenever ability to export arbitrary sha1 will be
allowed too. Can anybody clarify that for me please?
Regards,
Zdenek Crha
On Wed, Feb 29, 2012 at 08:45:55AM +0100, Zdenek Crha wrote:
I would like to ask a question about commit restriction added to git
archive by commit (ee27ca4a: archive: don't let remote clients get
unreachable commits, 2011-11-17) and following efforts to loosen them
a bit.
In out company we are using git together with source indexing. We
store a git command for retrieval of source code file that was used
for building into pdb file(s). Currently, we are using an invocation
of git archive with --remote parameter and commit sha1 to export
exactly the source code that was used for build.
The above mentioned commit removed possibility to do that. I have read
about efforts to loosen the restrictions,
but I'm not sure whenever ability to export arbitrary sha1 will be
allowed too. Can anybody clarify that for me please?
The plans for loosening are still up in the air, as we didn't have real
data on whether people were using this feature or not. I do have patches
ready that loosen the restriction based on the details of the name
lookup, which would allow things which started a traversal from a ref,
like "foo~5". But it would explicitly not allow an arbitrary sha1.
The only way to correctly handle an arbitrary sha1 is to actually do a
reachability analysis from the refs. That's what we do with upload-pack
(which handles regular fetch and clone requests). However, handling the
general case of fetching an arbitrary tree would mean we would have to
look inside every commit to see if it contains the tree. And that can
get a bit expensive. It sounds like you are just asking for a commit
sha1, so for your case we could get away with just handling sha1s of
commits, and only allowing trees that are referenced by commit (e.g.,
"HEAD~5:subdir") or have an exact ref pointing to them (e.g., like the
linux v2.6.11-tree tag).
Yet another option would be to add a config option on the server repo to
turn off this safety check for git-archive. That is simple to do, and
sounds like it would handle your use case, as you control the repo. One
downside is that it is the server admin who must turn on the config
option, whereas it is the clients of the repo who might want to make the
bare-sha1 request. In a company, the admins (usually) have to listen to
the clients, but that is not always the case.
-Peff