On Wed, Jun 15, 2011 at 04:48:32PM -0700, Junio C Hamano wrote: > > will produce a gzip'd file. If we make the mapping decision > > locally, then running: > > > > git archive --remote=origin -o file.tar.gz HEAD > > > > will send "--format=tgz" to the remote side. The server will > > complain, saying that it doesn't know about the tgz format. > > As long as that complaint is clearly marked as coming from the remote > side, the user now knows that tgz is not supported, and can fall back to a > plain tar. It is. You can simulate with: $ git archive --format=foobar --remote=. HEAD remote: fatal: Unknown archive format 'foobar' remote: git upload-archive: archiver died with error fatal: sent error to the client: git upload-archive: archiver died with error Or if you want to be really thorough and you have an old git lying around, you can see the format auto-selection triggers the same code: $ git archive -o foo.tar.gz --remote=. --exec='git.v1.7.5 upload-archive' HEAD remote: fatal: Unknown archive format 'tgz' fatal: sent error to the client: git upload-archive: archiver died with error remote: git upload-archive: archiver died with error > Am I being naÃve thinking that barfing (and assuming that the user > understands why the remote end barfed) actually is a good thing? No, I think barfing is totally fine there. I worry more about the cases where we silently produce a format the user was not expecting (the way mine is coded, it is "the server knows about .tar.gz, but the client does not; I expect gzip, but I get regular tar"). -Peff -- 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