git-archive is a command to make TAR and ZIP archives of a git tree.
It helps prevent a proliferation of git-{format}-tree commands.
Instead of directly calling git-{tar,zip}-tree command, it defines
a very simple API, that archiver should implement and register in
"git-archive.c". This API is made up by 2 functions whose prototype
is defined in "archive.h" file.
- The first one is used to parse 'extra' parameters which have
signification only for the specific archiver. That would allow
different archive backends to have different kind of options.
- The second one is used to ask to an archive backend to build
the archive given some already resolved parameters.
The main reason for making this API is to avoid using
git-{tar,zip}-tree commands, hence making them useless. Maybe it's
time for them to die ?
It also implements remote operations by defining a very simple
protocol: it first sends the name of the specific uploader followed
the repository name (git-upload-tar git://example.org/repo.git).
Then it sends "arguments" key word followed by all options given
when invoking 'git-archive'.
The remote protocol is implemented in "git-archive.c" for client
side and is triggered by "--remote=<repo>" option. For example,
to fetch a TAR archive in a remote repo, you can issue:
$ git archive --format=tar --remote=git://xxx/yyy/zzz.git HEAD
We choose to not make a new command "git-fetch-archive" for example,
avoind one more GIT command which should be nice for users (less
commands to remember, keeps existing --remote option).
Signed-off-by: Franck Bui-Huu <redacted>
---
.gitignore | 1
Makefile | 3 -
archive.h | 43 ++++++++
builtin-archive.c | 262 +++++++++++++++++++++++++++++++++++++++++++++++++++
builtin-tar-tree.c | 66 +++++++++++++
builtin.h | 1
generate-cmdlist.sh | 1
git.c | 1
8 files changed, 377 insertions(+), 1 deletions(-)
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:39
"Franck Bui-Huu" [off-list ref] writes:
git-archive is a command to make TAR and ZIP archives of a git tree.
It helps prevent a proliferation of git-{format}-tree commands.
Thanks. I like the overall structure, at least mostly.
Also dropping -tree suffix from the command name is nice, short
and sweet.
Obviously I cannot apply this patch because it is totally
whitespace damaged, but here are some comments.
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.
Also, you are passing "reason" around from everywhere, but that
is used by the caller to pass it to error(), so it might be
simpler to just call error() when you want to assign to *reason,
and make an error return. The caller does not have to do
anything if you do that. Your way might interact with the
remote protocol better, though -- I haven't thought this part
through yet so do not take this as a serious objection, but just
a comment.
Somehow "struct foo_struct" makes me feel uneasy, when I do not
see the reason to call it "struct foo".
Also, the first three fields are permanent property of the
archiver while two are to wrap runtime arguments of one
particular invocation. I would have liked...
+extern struct archiver_struct archivers[];
... this array to have only the former, and a separate structure
"struct archive_args" to be defined.
struct archive_args {
const char *remote;
const char *prefix;
};
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.
Then a specific parse_extra implementation can be written like this:
static struct tar_archive_args {
struct archive_args a;
int z_compress;
...
};
struct archive_args *
tar_archive_parse_extra(int ac, const char **av)
{
struct tar_archive_args *args = xcalloc(1, sizeof(*args));
while (ac--) {
const char *arg = *++av;
if (arg[0] == '-' &&
'0' <= arg[1] && arg[1] <= '9')
args->z_compress = arg[1] - '0';
...
}
return (struct archive_args *)args;
}
and this can be passed to tar_archive_write_archive as an
argument.
+extern int parse_treeish_arg(const char **argv,
+ struct tree **tree,
+ const unsigned char **commit_sha1,
+ time_t *archive_time,
+ const char *prefix,
+ const char **reason);
+extern int write_tar_archive(struct tree *tree,
+ const unsigned char *commit_sha1,
+ const char *prefix,
+ time_t time,
+ const char **pathspec);
I suspect we would want "struct tree_desc" based interface,
instead of "struct tree".
I do not think "-[0-9]" belongs to generic "git-archive". It
does not make much sense to run compress on zip output. More
like:
git-archive --format=<fmt> [--prefix=<prefix>] [format specific options] <tree-ish> [path...]
It has one potential advantage, though -- git-daemon _could_
look at it and notice that the client asks for too expensive
compression level. But I do not think it is the only way to
achive that to make "-[0-9]" a generic option.
+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?
Parameter concatenation with SP is a bad idea for two reasons.
You cannot have SP in argument. Also packet_write() may not
like the length of the arguments.
A sequence of one argument per packet, with prefix "argument "
for future extension so that we can send other stuff if/when
needed, followed by a flush would be preferred.
+ /* Now, start reading from fd[0] and spit it out to stdout */
+ rv = copy_fd(fd[0], 1);
+ close(fd[0]);
+ rv |= finish_connect(pid);
It was painful to bolt progress indicator support onto original
upload-pack protocol, while making sure that older and newer
clients and servers interoperate with each other. Since this is
a new protocol, we should start with the side-band support from
the beginning (see upload-pack and look for use_sideband).
Instead of sending the payload straight out, upload-archive side
would read from the underlying archiver, and send it with
one-byte prefix to say if it is a normal payload (band 1),
message to stderr used to show progress indicator and error
messages (band 2), or error exit situation (band 3). The client
side here would receive the packetized data and do the reverse.
I like the simplicity of just optionally sending one subtree (or
the whole thing), but I think this part would be made more
efficient if we go with "struct tree_desc" based interface.
Also I wonder how this interacts with the pathspec you take from
the command line. Personally I think this single subtree
support is good enough and limiting with pathspec is not needed.
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 ?
Also, you are passing "reason" around from everywhere, but that
is used by the caller to pass it to error(), so it might be
simpler to just call error() when you want to assign to *reason,
and make an error return. The caller does not have to do
anything if you do that. Your way might interact with the
remote protocol better, though -- I haven't thought this part
through yet so do not take this as a serious objection, but just
a comment.
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.
Somehow "struct foo_struct" makes me feel uneasy, when I do not
see the reason to call it "struct foo".
no strong feeling here. I'll call it "struct archiver". BTW there
are a couple of "struct foo_struct" in git source...
Also, the first three fields are permanent property of the
archiver while two are to wrap runtime arguments of one
particular invocation. I would have liked...
'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. It completely change
the behaviour of git-archive when it is used.
quoted
+extern struct archiver_struct archivers[];
... this array to have only the former, and a separate structure
"struct archive_args" to be defined.
struct archive_args {
const char *remote;
const char *prefix;
};
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.
Therefore we have to free this embedded structure somewhere.
We could have the following structures in archive.h, but we need
to export all these archiver backend definitions.
struct tar_archive_args {
int z_compress;
};
struct tar_archive_args {
[...]
};
struct archive_args {
const char *prefix;
struct tree *tree;
const unsigned char *commit_sha1;
const char *prefix;
time_t time;
const char **pathspec;
union {
struct tar_archive_args tar_args;
struct zip_archive_args zip_args;
} u;
};
struct archiver {
const char *name;
write_archive_fn_t write_archive;
parse_extra_args_fn_t parse_extra;
const char *remote;
};
typedef int (*write_archive_fn_t)(struct archive_args *archive_args);
Then a specific parse_extra implementation can be written like this:
static struct tar_archive_args {
struct archive_args a;
int z_compress;
...
};
struct archive_args *
tar_archive_parse_extra(int ac, const char **av)
{
struct tar_archive_args *args = xcalloc(1, sizeof(*args));
while (ac--) {
const char *arg = *++av;
if (arg[0] == '-' &&
'0' <= arg[1] && arg[1] <= '9')
args->z_compress = arg[1] - '0';
...
}
return (struct archive_args *)args;
}
and this can be passed to tar_archive_write_archive as an
argument.
quoted
+extern int parse_treeish_arg(const char **argv,
+ struct tree **tree,
+ const unsigned char **commit_sha1,
+ time_t *archive_time,
+ const char *prefix,
+ const char **reason);
+extern int write_tar_archive(struct tree *tree,
+ const unsigned char *commit_sha1,
+ const char *prefix,
+ time_t time,
+ const char **pathspec);
I suspect we would want "struct tree_desc" based interface,
instead of "struct tree".
I do not think "-[0-9]" belongs to generic "git-archive". It
does not make much sense to run compress on zip output. More
like:
I forgot to remove that.
git-archive --format=<fmt> [--prefix=<prefix>] [format specific options] <tree-ish> [path...]
I forgot to change that.
quoted
+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. It will
map these services to the generic "git-upload-archive" command.
One benefit is that we could still disable TAR format and enable
TGZ one. Please take a look to the second patch that adds
git-upload-archive command.
Parameter concatenation with SP is a bad idea for two reasons.
You cannot have SP in argument. Also packet_write() may not
like the length of the arguments.
A sequence of one argument per packet, with prefix "argument "
for future extension so that we can send other stuff if/when
needed, followed by a flush would be preferred.
Absolutely.
quoted
+ /* Now, start reading from fd[0] and spit it out to stdout */
+ rv = copy_fd(fd[0], 1);
+ close(fd[0]);
+ rv |= finish_connect(pid);
It was painful to bolt progress indicator support onto original
upload-pack protocol, while making sure that older and newer
clients and servers interoperate with each other. Since this is
a new protocol, we should start with the side-band support from
the beginning (see upload-pack and look for use_sideband).
Instead of sending the payload straight out, upload-archive side
would read from the underlying archiver, and send it with
one-byte prefix to say if it is a normal payload (band 1),
message to stderr used to show progress indicator and error
messages (band 2), or error exit situation (band 3). The client
side here would receive the packetized data and do the reverse.
I like the simplicity of just optionally sending one subtree (or
the whole thing), but I think this part would be made more
efficient if we go with "struct tree_desc" based interface.
Also I wonder how this interacts with the pathspec you take from
the command line. Personally I think this single subtree
support is good enough and limiting with pathspec is not needed.
As I said in a previous email, I'm new with git internals. I prefer
let that part to others who better have a better knowledge on the
subject. I'll dig into that later though...
The type of the first argument might have to be different,
depending on performance analysis by Rene on struct tree vs
struct tree_desc.
OK. We'll wait for Rene.
The performance difference I noticed was caused by a memleak; the speed
advantage of a struct tree_desc based traverser is significant if you
look only at the traversers' performance, but it is lost in the noise
of the "real" work that the payload function is doing (see my other
mail).
quoted
quoted
+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. It will
map these services to the generic "git-upload-archive" command.
One benefit is that we could still disable TAR format and enable
TGZ one. Please take a look to the second patch that adds
git-upload-archive command.
I don't think git-daemon should need to care about specific
archivers. Policy decisions, like disallowing certain archive types
or compression levels, should be made in git-upload-archive. This
way all code regarding archive uploading is found in one place:
git-upload-archive. We can keep git-upload-tar as a legacy
interface, but please use only git-upload-archive for the new stuff
(and not git-upload-zip etc.).
I like the simplicity of just optionally sending one subtree (or
the whole thing), but I think this part would be made more
efficient if we go with "struct tree_desc" based interface.
Also I wonder how this interacts with the pathspec you take from
the command line. Personally I think this single subtree
support is good enough and limiting with pathspec is not needed.
[Note: There's potential for confusion here because we have two
types of prefixes. One is the present working directory inside the
git archive, the other is the one specified with --prefix=. Here
we have the working directory kind of prefix.]
IMHO should work like in the following example, and the code above
cuts off the Documentation part:
$ cd Documentation
$ git-archive --format=tar --prefix=v1.0/ HEAD howto | tar tf -
v1.0/howto/
v1.0/howto/isolate-bugs-with-bisect.txt
...
I agree that simple subtree matching would be enough, at least for
now.
René
From: Jakub Narebski <hidden> Date: 2016-06-15 22:42:39
Rene Scharfe wrote:
IMHO should work like in the following example, and the code above
cuts off the Documentation part:
$ cd Documentation
$ git-archive --format=tar --prefix=v1.0/ HEAD howto | tar tf -
v1.0/howto/
v1.0/howto/isolate-bugs-with-bisect.txt
...
I agree that simple subtree matching would be enough, at least for
now.
What about
$ git-archive --format=tar --prefix=v1.0/ HEAD:Documentation/howto
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
IMHO should work like in the following example, and the code above
cuts off the Documentation part:
$ cd Documentation $ git-archive --format=tar --prefix=v1.0/ HEAD howto | tar tf -
v1.0/howto/
v1.0/howto/isolate-bugs-with-bisect.txt ...
I agree that simple subtree matching would be enough, at least for
now.
What about
$ git-archive --format=tar --prefix=v1.0/ HEAD:Documentation/howto
That is fine, too (cutting off Documentation/howto).
My comment above was about the piece of code that handles cd'ing around in
the repository. git-tar-tree ignores the current working directory -- you
always get the full tree put into your tar file, and you have to do the
"trick" you mentioned if you want to archive only a subtree. This is a bit
strange, so I think we should do it right from the start in git-archive.
René