From: Junio C Hamano <junkio@cox.net>
To: Franck <vagabon.xyz@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/2] Add git-archive
Date: Wed, 06 Sep 2006 14:42:49 -0700 [thread overview]
Message-ID: <7vac5c7jty.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <44FED12E.7010409@innova-card.com> (Franck Bui-Huu's message of "Wed, 06 Sep 2006 15:46:22 +0200")
Franck Bui-Huu <vagabon.xyz@gmail.com> writes:
>>> +typedef int (*parse_extra_args_fn_t)(int argc,
>>> + const char **argv,
>>> + const char **reason);
>>> +
>>
>> I do not see a way for parse_extra to record the parameter it
>> successfully parsed, other than in a source-file-global, static
>> variable. Not a very nice design for a library, if we are
>> building one from scratch.
>
> Interesting, could you explain why static variables are not nice ?
Mostly taste and a little bit of re-entrancy worries.
> You might have missed my second patch:
>
> "[PATCH 2/2] Add git-upload-archive"
>
> Basically the server can also use 'reason' to report a failure
> description during NACK. I find it more useful than the simple
> "server sent EOF" error message.
That's a good intention, but we would also need to convey the
"server side found problem and died with these error() output"
anyway, so it would be covered either way (see how error()/die()
messages from git-upload-pack are given to git-fetch-pack over
the wire).
> 'remote' case is not a generic argument that can be passed to
> archiver backends. Remember, the archiver backends only do local
> operation. They do not know about remote protocol which is part
> of git-archive command. That's the reason why I think we shouldn't
> make this field part of arguments structure.
Ok. Passing that as a separate paramter would make sense.
>> After parse_archive_args finds the archiver specified with
>> --format=*, it can call its parse_extra to retrieve a suitable
>> struct that has struct archive_args embedded at the beginning,
>> and then set remote and prefix on the returned structure.
>
> One bad side is that we need to malloc this embedded structure.
Not at all, if you read the example I did you would notice that
I changed parse_extra for each backend to return this structure
allocated for that particular backend.
>>> +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?
next prev parent reply other threads:[~2006-09-06 21:42 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-05 12:16 [PATCH 1/2] Add git-archive Franck Bui-Huu
2006-09-05 19:23 ` Junio C Hamano
2006-09-06 13:46 ` Franck Bui-Huu
2006-09-06 20:14 ` Rene Scharfe
2006-09-06 20:29 ` Jakub Narebski
2006-09-08 20:21 ` Rene Scharfe
2006-09-06 21:42 ` Junio C Hamano [this message]
2006-09-07 6:32 ` Franck Bui-Huu
2006-09-07 7:19 ` Junio C Hamano
2006-09-07 7:53 ` Franck Bui-Huu
2006-09-07 8:16 ` Junio C Hamano
2006-09-07 13:08 ` Add git-archive [take #2] Franck Bui-Huu
2006-09-07 13:12 ` [PATCH 1/4] Add git-archive Franck Bui-Huu
2006-09-08 2:35 ` Junio C Hamano
2006-09-08 9:00 ` Franck Bui-Huu
2006-09-08 20:21 ` Rene Scharfe
2006-09-09 14:31 ` Franck Bui-Huu
2006-09-09 15:02 ` Rene Scharfe
2006-09-09 15:25 ` Franck Bui-Huu
2006-09-07 13:12 ` [PATCH 2/4] git-archive: wire up TAR format Franck Bui-Huu
2006-09-08 20:21 ` Rene Scharfe
2006-09-08 21:42 ` Junio C Hamano
2006-09-09 1:53 ` Junio C Hamano
2006-09-09 15:02 ` Rene Scharfe
2006-09-09 15:10 ` Franck Bui-Huu
2006-09-09 19:42 ` Junio C Hamano
2006-09-10 16:10 ` [PATCH] Use xstrdup instead of strdup in builtin-{tar,zip}-tree.c Rene Scharfe
2006-09-09 14:38 ` [PATCH 2/4] git-archive: wire up TAR format Franck Bui-Huu
2006-09-07 13:12 ` [PATCH 3/4] git-archive: wire up ZIP format Franck Bui-Huu
2006-09-07 13:12 ` [PATCH 4/4] Add git-upload-archive Franck Bui-Huu
2006-09-07 17:26 ` Add git-archive [take #2] Franck Bui-Huu
2006-09-08 0:37 ` Junio C Hamano
2006-09-08 8:18 ` Franck Bui-Huu
2006-09-08 8:47 ` Jakub Narebski
2006-09-08 8:58 ` Junio C Hamano
2006-09-08 9:43 ` Franck Bui-Huu
2006-09-08 21:42 ` Junio C Hamano
2006-09-08 20:21 ` Rene Scharfe
2006-09-08 21:42 ` Junio C Hamano
2006-09-06 20:17 ` [PATCH 1/2] Add git-archive Rene Scharfe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vac5c7jty.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=vagabon.xyz@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).