Jeff King 56baa61d01 archive: move file extension format-guessing lower ... The process for guessing an archive output format based on the filename is something like this: a. parse --output in cmd_archive; check the filename against a static set of mapping heuristics (right now it just matches ".zip" for zip files). b. if found, stick a fake "--format=zip" at the beginning of the arguments list (if the user did specify a --format manually, the later option will override our fake one) c. if it's a remote call, ship the arguments to the remote (including the fake), which will call write_archive on their end d. if it's local, ship the arguments to write_archive locally There are two problems: 1. The set of mappings is static and at too high a level. The write_archive level is going to check config for user-defined formats, some of which will specify extensions. We need to delay lookup until those are parsed, so we can match against them. 2. For a remote archive call, our set of mappings (or formats) may not match the remote side's. This is OK in practice right now, because all versions of git understand "zip" and "tar". But as new formats are added, there is going to be a mismatch between what the client can do and what the remote server can do. To fix (1), this patch refactors the location guessing to happen at the write_archive level, instead of the cmd_archive level. So instead of sticking a fake --format field in the argv list, we actually pass a "name hint" down the callchain; this hint is used at the appropriate time to guess the format (if one hasn't been given already). This patch leaves (2) unfixed. The name_hint is converted to a "--format" option as before, and passed to the remote. This means the local side's idea of how extensions map to formats will take precedence. Another option would be to pass the name hint to the remote side and let the remote choose. This isn't a good idea for two reasons: 1. There's no room in the protocol for passing that information. We can pass a new argument, but older versions of git on the server will choke on it. 2. Letting the remote side decide creates a silent inconsistency in user experience. Consider the case that the locally installed git knows about the "tar.gz" format, but a remote server doesn't. Running "git archive -o foo.tar.gz" will use the tar.gz format. If we use --remote, and the local side chooses the format, then we send "--format=tar.gz" to the remote, which will complain about the unknown format. But if we let the remote side choose the format, then it will realize that it doesn't know about "tar.gz" and output uncompressed tar without even issuing a warning. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>		2011-06-22 11:12:35 -07:00
..
add.c
annotate.c
apply.c
archive.c	archive: move file extension format-guessing lower	2011-06-22 11:12:35 -07:00
bisect--helper.c
blame.c
branch.c
bundle.c
cat-file.c
check-attr.c
check-ref-format.c
checkout-index.c
checkout.c
clean.c
clone.c
commit-tree.c
commit.c
config.c
count-objects.c
describe.c
diff-files.c
diff-index.c
diff-tree.c
diff.c
fast-export.c
fetch-pack.c
fetch.c
fmt-merge-msg.c
for-each-ref.c
fsck.c
gc.c
grep.c
hash-object.c
help.c
index-pack.c
init-db.c
log.c
ls-files.c
ls-remote.c
ls-tree.c
mailinfo.c
mailsplit.c
merge-base.c
merge-file.c
merge-index.c
merge-ours.c
merge-recursive.c
merge-tree.c
merge.c
mktag.c
mktree.c
mv.c
name-rev.c
notes.c
pack-objects.c
pack-redundant.c
pack-refs.c
patch-id.c
prune-packed.c
prune.c
push.c
read-tree.c
receive-pack.c
reflog.c
remote-ext.c
remote-fd.c
remote.c
replace.c
rerere.c
reset.c
rev-list.c
rev-parse.c
revert.c
rm.c
send-pack.c
shortlog.c
show-branch.c
show-ref.c
stripspace.c
symbolic-ref.c
tag.c
tar-tree.c
unpack-file.c
unpack-objects.c
update-index.c
update-ref.c
update-server-info.c
upload-archive.c	archive: move file extension format-guessing lower	2011-06-22 11:12:35 -07:00
var.c
verify-pack.c
verify-tag.c
write-tree.c