Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>

diff --git a/.gitignore b/.gitignore
index 55cd984..58a7c92 100644
--- a/.gitignore
+++ b/.gitignore
@@ -124,6 +124,7 @@ git-verify-pack
 git-verify-tag
 git-whatchanged
 git-write-tree
+git-zip-tree
 git-core-*/?*
 gitweb/gitweb.cgi
 test-date
-

[ message continues ]

That is sensible.

Although it was my fault applying it already to "master" without
asking this question first, I started to wonder how many more
archive format people would want, and if it might make more
sense to consolidate git-*-tree into a single frontend with an
option to specify the archiver.

We would obviously need to keep git-tar-tree as a backward
compatibility alias for "git archive-tree -f tar", but doing
things that way we do not have to introduce unbounded number of
new git-{zip,rar,...}-tree programs.



-

[ message continues ]

That thought occurred to me, too.  I guess there are not that many more
interesting archive formats, though.  Can we defer adding
git-archive-tree until a third archive format command appears?  I won't
submit another one, I promise. ;-)

Ren
[ message continues ]

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.



-

[ message continues ]

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.

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).

Ren
[ message continues ]

I think so.  I never liked the --remote support that was done

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.





-

[ message continues ]