{"thread":{"id":"47235","subject":"git archive --remote should generate tar.gz format indicated by -o filename","startedAt":"2017-11-18T22:25:12Z","lastAt":"2017-11-18T22:25:12Z","messageCount":1,"participants":["git-scm@nuclearsunshine.com"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"332827","messageId":"1511043401.28381.11.camel@nuclearsunshine.com","threadId":"47235","inReplyTo":null,"subject":"git archive --remote should generate tar.gz format indicated by -o filename","fromName":"","fromEmail":"git-scm@nuclearsunshine.com","sentAt":"2017-11-18T22:16:41Z","receivedAt":"2017-11-18T22:25:12Z","isPatch":false,"sender":{"key":"git-scm@nuclearsunshine.com","avatar":null},"body":"git archive -o name.tar.gz generates a gzipped file without needing an\nexplicit --format switch.\n\nHowever, git archive -o name.tar.gz --remote [url] generates a tar\nfile, which is unexpected, bandwidth-heavier, and additionally in some\ncases it's not immediately obvious that this has happened.\n\ngit archive -o name.tar.gz --remote [url] --format tar.gz generates a\ngzipped file, so there's obviously no limitation with e.g. git-upload-\narchive.\n\nGiven the above, either git archive or git-upload-archive should apply\nthe same tar.gz filename heuristic and generate the expected format.\n\nPresumably e.g. tar.xz support when using --remote would be more\nproblematic since, in the local case, it involves specifying an\narbitrary command.\n"}]}