{"thread":{"id":"5405","subject":"[PATCH] Add git-zip-tree to .gitignore","startedAt":"2006-08-27T11:19:49Z","lastAt":"2006-08-28T22:43:41Z","messageCount":6,"participants":["Rene Scharfe","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"25981","messageId":"44F17FD5.2030000@lsrfire.ath.cx","threadId":"5405","inReplyTo":null,"subject":"[PATCH] Add git-zip-tree to .gitignore","fromName":"Rene Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2006-08-27T11:19:49Z","receivedAt":"2006-08-27T11:19:49Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Signed-off-by: Rene Scharfe \n\ndiff --git a/.gitignore b/.gitignore\nindex 55cd984..58a7c92 100644\n--- a/.gitignore\n+++ b/.gitignore\n@@ -124,6 +124,7 @@ git-verify-pack\n git-verify-tag\n git-whatchanged\n git-write-tree\n+git-zip-tree\n git-core-*/?*\n gitweb/gitweb.cgi\n test-date\n"},{"id":"26010","messageId":"7vlkp9x2b9.fsf@assigned-by-dhcp.cox.net","threadId":"5405","inReplyTo":"44F17FD5.2030000@lsrfire.ath.cx","subject":"Re: [PATCH] Add git-zip-tree to .gitignore","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-27T22:04:58Z","receivedAt":"2006-08-27T22:04:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rene Scharfe writes:\n\n> Signed-off-by: Rene Scharfe \n>\n> diff --git a/.gitignore b/.gitignore\n> index 55cd984..58a7c92 100644\n> --- a/.gitignore\n> +++ b/.gitignore\n> @@ -124,6 +124,7 @@ git-verify-pack\n> git-verify-tag\n> git-whatchanged\n> git-write-tree\n> +git-zip-tree\n> git-core-*/?*\n> gitweb/gitweb.cgi\n> test-date\n\nThat is sensible.\n\nAlthough it was my fault applying it already to \"master\" without\nasking this question first, I started to wonder how many more\narchive format people would want, and if it might make more\nsense to consolidate git-*-tree into a single frontend with an\noption to specify the archiver.\n\nWe would obviously need to keep git-tar-tree as a backward\ncompatibility alias for \"git archive-tree -f tar\", but doing\nthings that way we do not have to introduce unbounded number of\nnew git-{zip,rar,...}-tree programs.\n"},{"id":"26012","messageId":"44F21E0B.9010600@lsrfire.ath.cx","threadId":"5405","inReplyTo":"7vlkp9x2b9.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add git-zip-tree to .gitignore","fromName":"Rene Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2006-08-27T22:34:51Z","receivedAt":"2006-08-27T22:34:51Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Junio C Hamano schrieb:\n> Although it was my fault applying it already to \"master\" without \n> asking this question first, I started to wonder how many more archive\n> format people would want, and if it might make more sense to\n> consolidate git-*-tree into a single frontend with an option to\n> specify the archiver.\n> \n> We would obviously need to keep git-tar-tree as a backward \n> compatibility alias for \"git archive-tree -f tar\", but doing things\n> that way we do not have to introduce unbounded number of new\n> git-{zip,rar,...}-tree programs.\n\nThat thought occurred to me, too. I guess there are not that many more\ninteresting archive formats, though. Can we defer adding\ngit-archive-tree until a third archive format command appears? I won't\nsubmit another one, I promise. ;-)\n\nRené\n"},{"id":"26014","messageId":"7vhczxvlar.fsf@assigned-by-dhcp.cox.net","threadId":"5405","inReplyTo":"44F21E0B.9010600@lsrfire.ath.cx","subject":"Re: [PATCH] Add git-zip-tree to .gitignore","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-27T22:57:48Z","receivedAt":"2006-08-27T22:57:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rene Scharfe writes:\n\n> Junio C Hamano schrieb:\n>> Although it was my fault applying it already to \"master\" without \n>> asking this question first, I started to wonder how many more archive\n>> format people would want, and if it might make more sense to\n>> consolidate git-*-tree into a single frontend with an option to\n>> specify the archiver.\n>> \n>> We would obviously need to keep git-tar-tree as a backward \n>> compatibility alias for \"git archive-tree -f tar\", but doing things\n>> that way we do not have to introduce unbounded number of new\n>> git-{zip,rar,...}-tree programs.\n>\n> That thought occurred to me, too. I guess there are not that many more\n> interesting archive formats, though. Can we defer adding\n> git-archive-tree until a third archive format command appears? I won't\n> submit another one, I promise. ;-)\n\nI was more worried about possibly having to do --remote once in\neach for tar-tree and zip-tree in git-daemon. The version of\ndaemon currently in \"pu\" can allow git-tar-tree to be accessed\nfrom the client via git:// URL.\n"},{"id":"26069","messageId":"44F36E03.9090802@lsrfire.ath.cx","threadId":"5405","inReplyTo":"7vhczxvlar.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add git-zip-tree to .gitignore","fromName":"Rene Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2006-08-28T22:28:19Z","receivedAt":"2006-08-28T22:28:19Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Junio C Hamano schrieb:\n> Rene Scharfe writes:\n> \n>> Junio C Hamano schrieb:\n>>> Although it was my fault applying it already to \"master\" without \n>>> asking this question first, I started to wonder how many more archive\n>>> format people would want, and if it might make more sense to\n>>> consolidate git-*-tree into a single frontend with an option to\n>>> specify the archiver.\n>>>\n>>> We would obviously need to keep git-tar-tree as a backward \n>>> compatibility alias for \"git archive-tree -f tar\", but doing things\n>>> that way we do not have to introduce unbounded number of new\n>>> git-{zip,rar,...}-tree programs.\n>> That thought occurred to me, too. I guess there are not that many more\n>> interesting archive formats, though. Can we defer adding\n>> git-archive-tree until a third archive format command appears? I won't\n>> submit another one, I promise. ;-)\n> \n> I was more worried about possibly having to do --remote once in\n> each for tar-tree and zip-tree in git-daemon. The version of\n> daemon currently in \"pu\" can allow git-tar-tree to be accessed\n> from the client via git:// URL.\n\nGood point. And especially for net transfers a compressed format like\nZIP or TGZ (not yet implemented) would be better.\n\nWould it make sense to have just one multiplexer command? I.e.\nsomething like this:\n\n git-archive -f [extra] []\n git-archive -f [extra] --upload []\n git-archive -f [extra] --remote= []\n\n[extra] stands for format specific options like the compression ratio\nfor ZIP. The protocol spoken by upload and --remote would need to be\nextended to be able to specify the format and any format specific options.\n\nWhile we're discussing the command line interface, would it make sense\nto support path specs, like e.g. ls-tree does? Like this:\n\n git-archive -f [extra] [--prefix=] []\n\nPersonally, I don't see the need for path specs for archive creation,\nbut IF we want to introduce them then the best time to do it would be\nnow, at the same time as introducing git-archive (or git-archive-tree).\n\nRené\n"},{"id":"26070","messageId":"7vd5akqy5e.fsf@assigned-by-dhcp.cox.net","threadId":"5405","inReplyTo":"44F36E03.9090802@lsrfire.ath.cx","subject":"Re: [PATCH] Add git-zip-tree to .gitignore","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-28T22:43:41Z","receivedAt":"2006-08-28T22:43:41Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rene Scharfe writes:\n\n> Junio C Hamano schrieb:\n>> \n>> I was more worried about possibly having to do --remote once in\n>> each for tar-tree and zip-tree in git-daemon. The version of\n>> daemon currently in \"pu\" can allow git-tar-tree to be accessed\n>> from the client via git:// URL.\n>\n> Good point. And especially for net transfers a compressed format like\n> ZIP or TGZ (not yet implemented) would be better.\n>\n> Would it make sense to have just one multiplexer command? I.e.\n> something like this:\n>\n> git-archive -f [extra] []\n> git-archive -f [extra] --upload []\n> git-archive -f [extra] --remote= []\n>\n> [extra] stands for format specific options like the compression ratio\n> for ZIP. The protocol spoken by upload and --remote would need to be\n> extended to be able to specify the format and any format specific options.\n\nI think so. I never liked the --remote support that was done\ninside tar-tree myself and hoped there would be better ways.\n\n> While we're discussing the command line interface, would it make sense\n> to support path specs, like e.g. ls-tree does? Like this:\n>\n> git-archive -f [extra] [--prefix=] []\n>\n> Personally, I don't see the need for path specs for archive creation,\n> but IF we want to introduce them then the best time to do it would be\n> now, at the same time as introducing git-archive (or git-archive-tree).\n\nWell people may want to say more than one to archive only\n\"include/asm-i386\" and \"arch/i386\" directories, but other than\nthat, naming with : syntax would be\nenough. But I agree with you that it would be now IF we want to\ndo this. I am neutral, perhaps slightly in favor.\n"}]}