Rene Scharfe <rene.scharfe@xxxxxxxxxxxxxx> writes: > Junio C Hamano schrieb: >> >> I was more worried about possibly having to do --remote once in >> each for tar-tree and zip-tree in git-daemon. The version of >> daemon currently in "pu" can allow git-tar-tree to be accessed >> from the client via git:// URL. > > Good point. And especially for net transfers a compressed format like > ZIP or TGZ (not yet implemented) would be better. > > Would it make sense to have just one multiplexer command? I.e. > something like this: > > git-archive -f <format> [extra] <tree-ish> [<base>] > git-archive -f <format> [extra] --upload <tree-ish> [<base>] > git-archive -f <format> [extra] --remote=<url> <tree-ish> [<base>] > > [extra] stands for format specific options like the compression ratio > for ZIP. The protocol spoken by upload and --remote would need to be > extended to be able to specify the format and any format specific options. I think so. I never liked the --remote support that was done inside tar-tree myself and hoped there would be better ways. > While we're discussing the command line interface, would it make sense > to support path specs, like e.g. ls-tree does? Like this: > > git-archive -f <format> [extra] [--prefix=<base>] <tree-ish> [<path>] > > Personally, I don't see the need for path specs for archive creation, > but IF we want to introduce them then the best time to do it would be > now, at the same time as introducing git-archive (or git-archive-tree). Well people may want to say more than one <path> to archive only "include/asm-i386" and "arch/i386" directories, but other than that, naming <tree-ish> with <revision>:<path> syntax would be enough. But I agree with you that it would be now IF we want to do this. I am neutral, perhaps slightly in favor. - 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