Re: Proposed approaches to supporting HTTP remotes in "git archive"

[Junio C Hamano <gitster@pobox.com>]

Josh Steadmon <steadmon@google.com> writes:

> # Supporting HTTP remotes in "git archive"
>
> We would like to allow remote archiving from HTTP servers. There are a
> few possible implementations to be discussed:
>
> ## Shallow clone to temporary repo
>
> This approach builds on existing endpoints. Clients will connect to the
> remote server's git-upload-pack service and fetch a shallow clone of the
> requested commit into a temporary local repo. The write_archive()
> function is then called on the local clone to write out the requested
> archive.
>
> ...
>
> ## Summary
>
> Personally, I lean towards the first approach. It could give us an
> opportunity to remove server-side complexity; there is no reason that
> the shallow-clone approach must be restricted to the HTTP transport, and
> we could re-implement other transports using this method.  Additionally,
> it would allow clients to pull archives from remotes that would not
> otherwise support it.

I consider the first one (i.e. make a shallow clone and tar it up
locally) a hack that does *not* belong to "git archive --remote"
command, especially when it is only done to "http remotes".  The
only reason HTTP remotes are special is because there is no ready
"http-backend" equivalent that passes the "git archive" traffic over
smart-http transport, unlike the one that exists for "git
upload-pack".

It however still _is_ attractive to drive such a hack from "git
archive" at the UI level, as the end users do not care how ugly the
hack is ;-)  As you mentioned, the approach would work for any
transport that allows one-commit shallow clone, so it might become
more palatable if it is designed as a different _mode_ of operation
of "git archive" that is orthogonal to the underlying transport,
i.e.

  $ git archive --remote=<repo> --shallow-clone-then-local-archive-hack master

or

  $ git config archive.<repo>.useShallowCloneThenLocalArchiveHack true
  $ git archive --remote=<repo> master

It might turn out that it may work better than the native "git
archive" access against servers that offer both shallow clone
and native archive access.  I doubt a single-commit shallow clone
would benefit from reusing of premade deltas and compressed bases
streamed straight out of packfiles from the server side that much,
but you'd never know until you measure ;-)