Re: [PATCH 5/7] archive: refactor format-guessing from filename

From: Jeff King <peff@github.com>
Date: Jun 16, 2011, 00:34 UTC
Message-ID: <20110616003400.GB20355@sigill.intra.peff.net>
In-Reply-To: <7vmxhiirlb.fsf@alter.siamese.dyndns.org>

On Wed, Jun 15, 2011 at 04:48:32PM -0700, Junio C Hamano wrote:

Show 11 quoted lines

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