From: Junio C Hamano <junkio@cox.net>
Date: Mon, 28 Aug 2006 22:43:41 GMT
Subject: Re: [PATCH] Add git-zip-tree to .gitignore
Message-ID: <7vd5akqy5e.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <44F36E03.9090802@lsrfire.ath.cx>

Rene Scharfe <rene.scharfe@lsrfire.ath.cx> 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.