"Franck Bui-Huu" <vagabon.xyz@xxxxxxxxx> writes:
> sorry I wasn't clear. My point was that the structure need to be
> 'mallocated'. Which funtion allocate it doesn't matter, we will need
> to free it later. That's what I tried to avoid with the alternative I
> sent you in my previous email. Do you think we could use it ?
I do not think allocation and free matter much, but if you want
to do it that way, enumerating all the possible struct in one
place is fine by me for this application. After all we are not
defining a plug-in architecture that lets others to write their
archive backends and load them without recompiling git-archive
binary.
>> >>> +static int run_remote_archiver(struct archiver_struct *ar, int argc,
>> >>> + const char **argv)
>> >>> +{
>> >>> + char *url, buf[1024];
>> >>> + pid_t pid;
>> >>> + int fd[2];
>> >>> + int len, rv;
>> >>> +
>> >>> + sprintf(buf, "git-upload-%s", ar->name);
>> >>
>> >> Are you calling git-upload-{tar,zip,rar,...} here?
>> >
>> > yes. Actually git-upload-{tar,zip,...} commands are going to be
>> > removed, but git-daemon know them as a daemon service.
>>
>> That would break "git-archive --remove=ssh://site/repo treeish"
>> wouldn't it?
>
> Yes. But couldn't we make some alias like:
>...
> These alias would be internal to git (always defined)
You _could_ work things around by building special cases into
the system, but I would rather avoid doing that unless
necessary.
Is there a reason that "git-upload-archive --format=tar" is not
desirable at this point of the code?
-
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