Franck Bui-Huu schrieb:
> 2006/9/2, Rene Scharfe <rene.scharfe@xxxxxxxxxxxxxx>:
>> The two patches I sent are what I have been able to come up with so far.
>> The next step would be to add archive-neutral upload and download
>> support.
>>
>> Having thought a bit about it I propose to keep git-archive-tree for
>> local operations, only. It can be called by the uploader just like
>
> Well I don't see why putting the remote operations in an other file. I
> was more thinking on something like this:
>
> git-archive --format=<fmt> [--remote=<repo>] <tree-ish> [path...]
My intention was to put both halves of the wire protocol implementation
into the same source file. I still think this is a good idea, but of
course it's independent from any command line interface considerations.
Internally, remote and local operations do completely different things,
so it doesn't make sense to mix them. But users probably don't care
about such details and may prefer a single command to express "gimme
that archive, no matter if it's made here or there". OK, sort of.
> This main porcelain function would call directly functions provided by
> archivers lib. We will need to define an API which git-archive will
> use for local operations.
Yes, this would be write_archive_fn_t in archive.h.
> Symetrically, on the sever side we would have:
>
> git-upload-archive --format=<fmt> <repo> [path...]
No, git-upload-archive would accept only a single parameter: the path to
the repository. It'd receive all other options via the wire protocol,
just like git-upload-tar.
> used by git-daemon. It will deal with protocol, paths and use archiver's
> lib.
Except if you meant by this that git-daemon would handle the protocol
etc., which I'd disagree with ("It" is slightly ambiguous here).
> Eventually, we would have 2 commands:
>
> git-archive
> git-upload-archive
>
> and get ride of
>
> git-tar-tree
> git-zip-tree
> git-upload-tar
> git-upload-zip
Let's keep the git-<verb>-<object> nomenclature used for most commands
for the sake of consistency. In both cases you'd only type
git-archiv<TAB> anyway. ;-)
We could remove the existing commands git-upload-tar and git-zip-tree
right now, as they were never part of a release, yet. git-upload-zip
doesn't exist, yet, and git-tar-tree would probably survive as legacy
interface, calling git-archive-tree internals. Junio, am I correct
regarding the cool-blooded killing of unreleased commands?
>> git-tar-tree is now called by git-upload-tar. As Franck suggested, the
>> uploader should allow the list of archive formats it supports to be
>> restricted in a config file. The range of allowed compression levels
>> should also be configurable.
>>
>> Does it make sense to change the wire protocol to simply send the
>> command line options one by one?
>
> That would make sense if the number of options grow up. Currently the
> remote protocol had been written by Junio, I just pick up that part
> from git-tar-tree and put it into git-archive. But if we allow
> pathspec for remote operations, then we need to send them to the
> uploader.
If we simply send each option to the downloader without understanding
them then the uploader can be kept really simple. The protocol can be
kept simple, and it would be future-proof: we will never have to update
it. I'm a bit worried about the security implications of such a setup,
strangely _because_ I can't see a way to exploit it right now (and
because it allows arbitrary input, which we must be able to cope with
anyway).
>>
>> The interface could be something like this:
>>
>> git-download-archive <repo> <git-archive-tree options...>
>> git-upload-archive <directory>
>>
>> Or, if the big number of git command names is a concern:
>>
>
> I think it is, IMHO. And that's why I think we could have only one
> command for building localy/remotely archive whatever the format.
> git-archive should be a main procelain command, and we should get rid
> of git-{tar,zip}-tree commands.
OK, makes sense; users will never need to call git-upload-archive
directly, and having a single command for all archiving is a good thing.
My next steps will be to make traverse_tree() support path specs, in
order to achieve feature parity with read_tree_recursive(). I hope that
the former keeps being significantly faster than the latter even after
that. If it works out I'm going to convert git-zip-tree to use
traverse_tree().
Other tasks: morphing git-upload-tar into git-upload-archive,
replacing/enhancing the protocol, and adding a matching uploader
(--remote= option handler). I won't start with that stuff until I get
the performance sorted out. I hope this keeps me from stepping on your
toes (again), Franck. ;-)
Thanks,
René
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html