2005-06-03 00:50:17 +04:00
|
|
|
#!/bin/sh
|
|
|
|
#
|
|
|
|
# Copyright (C) 2005 Rene Scharfe
|
|
|
|
#
|
|
|
|
|
2013-11-10 19:47:29 +04:00
|
|
|
test_description='git archive and git get-tar-commit-id test
|
2005-06-03 00:50:17 +04:00
|
|
|
|
2005-06-03 20:21:23 +04:00
|
|
|
This test covers the topics of file contents, commit date handling and
|
|
|
|
commit id embedding:
|
2005-06-03 00:50:17 +04:00
|
|
|
|
|
|
|
The contents of the repository is compared to the extracted tar
|
|
|
|
archive. The repository contains simple text files, symlinks and a
|
2007-02-04 07:49:16 +03:00
|
|
|
binary file (/bin/sh). Only paths shorter than 99 characters are
|
2005-06-03 20:21:23 +04:00
|
|
|
used.
|
2005-06-03 00:50:17 +04:00
|
|
|
|
2013-11-10 19:47:29 +04:00
|
|
|
git archive applies the commit date to every file in the archive it
|
2005-06-03 00:50:17 +04:00
|
|
|
creates. The test sets the commit date to a specific value and checks
|
|
|
|
if the tar archive contains that value.
|
|
|
|
|
2013-11-10 19:47:29 +04:00
|
|
|
When giving git archive a commit id (in contrast to a tree id) it
|
2005-06-03 00:50:17 +04:00
|
|
|
embeds this commit id into the tar archive as a comment. The test
|
2007-07-03 09:52:14 +04:00
|
|
|
checks the ability of git get-tar-commit-id to figure it out from the
|
2005-06-03 00:50:17 +04:00
|
|
|
tar file.
|
|
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
2007-09-06 20:51:11 +04:00
|
|
|
SUBSTFORMAT=%H%n
|
2007-09-03 22:07:01 +04:00
|
|
|
|
2013-05-20 13:58:29 +04:00
|
|
|
test_lazy_prereq TAR_NEEDS_PAX_FALLBACK '
|
|
|
|
(
|
|
|
|
mkdir pax &&
|
|
|
|
cd pax &&
|
|
|
|
"$TAR" xf "$TEST_DIRECTORY"/t5000/pax.tar &&
|
|
|
|
test -f PaxHeaders.1791/file
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
t5000: simplify gzip prerequisite checks
In t5000, we test the built-in ".tar.gz" config for
git-archive. To make our tests portable, we check that we
have a way to both gzip and gunzip, and we respected
environment variables to point to alternate commands for
doing these operations.
However, the $GZIP variable did not actually do anything, as
changing it would not affect the baked-in value in
archive-tar.c. Moreover, setting the variable $GZIP
influences gzip itself. From the gzip man page:
The environment variable GZIP can hold a set of default
options for gzip. These options are interpreted first and
can be overwritten by explicit command line parameters.
We could rename this variable, and use it to set up custom
config (or even have a Makefile knob to affect the built
binary), but it is not worth the trouble; nobody has ever
reported a problem with the baked-in default, and they can
always change it via config if they need to. Let's just drop
the variable and use "gzip" in the test (keeping the
prerequisite, of course).
While we're at it, we can drop the GUNZIP variable and
prerequisite; it uses "gzip -d", so if we have GZIP, we
will have both.
We can also use test_lazy_prereq for the gzip prerequisite,
which is simpler and behaves more consistently with the rest
of git (e.g., by making output available when the test is
run with "-v").
Noticed-by: Christian Hesse <mail@eworm.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-03 17:21:40 +04:00
|
|
|
test_lazy_prereq GZIP 'gzip --version'
|
|
|
|
|
2013-05-20 13:58:29 +04:00
|
|
|
get_pax_header() {
|
|
|
|
file=$1
|
|
|
|
header=$2=
|
|
|
|
|
|
|
|
while read len rest
|
|
|
|
do
|
|
|
|
if test "$len" = $(echo "$len $rest" | wc -c)
|
|
|
|
then
|
|
|
|
case "$rest" in
|
|
|
|
$header*)
|
|
|
|
echo "${rest#$header}"
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
fi
|
|
|
|
done <"$file"
|
|
|
|
}
|
|
|
|
|
2013-05-20 13:58:26 +04:00
|
|
|
check_tar() {
|
|
|
|
tarfile=$1.tar
|
|
|
|
listfile=$1.lst
|
|
|
|
dir=$1
|
|
|
|
dir_with_prefix=$dir/$2
|
|
|
|
|
|
|
|
test_expect_success ' extract tar archive' '
|
|
|
|
(mkdir $dir && cd $dir && "$TAR" xf -) <$tarfile
|
|
|
|
'
|
|
|
|
|
2013-05-20 13:58:29 +04:00
|
|
|
test_expect_success TAR_NEEDS_PAX_FALLBACK ' interpret pax headers' '
|
|
|
|
(
|
|
|
|
cd $dir &&
|
|
|
|
for header in *.paxheader
|
|
|
|
do
|
|
|
|
data=${header%.paxheader}.data &&
|
2014-06-06 18:55:58 +04:00
|
|
|
if test -h $data || test -e $data
|
2013-05-20 13:58:29 +04:00
|
|
|
then
|
|
|
|
path=$(get_pax_header $header path) &&
|
|
|
|
if test -n "$path"
|
|
|
|
then
|
|
|
|
mv "$data" "$path"
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
2013-05-20 13:58:26 +04:00
|
|
|
test_expect_success ' validate filenames' '
|
|
|
|
(cd ${dir_with_prefix}a && find .) | sort >$listfile &&
|
|
|
|
test_cmp a.lst $listfile
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success ' validate file contents' '
|
|
|
|
diff -r a ${dir_with_prefix}a
|
|
|
|
'
|
|
|
|
}
|
|
|
|
|
2005-06-03 00:50:17 +04:00
|
|
|
test_expect_success \
|
|
|
|
'populate workdir' \
|
2013-05-20 13:58:25 +04:00
|
|
|
'mkdir a &&
|
2005-06-03 00:50:17 +04:00
|
|
|
echo simple textfile >a/a &&
|
2013-05-20 13:58:29 +04:00
|
|
|
ten=0123456789 && hundred=$ten$ten$ten$ten$ten$ten$ten$ten$ten$ten &&
|
|
|
|
echo long filename >a/four$hundred &&
|
2005-06-03 00:50:17 +04:00
|
|
|
mkdir a/bin &&
|
t5000 on Windows: do not mistake "sh.exe" as "sh"
In their effort to emulate POSIX as close as possible, the MSYS tools
and Cygwin treat the file name "foo.exe" as "foo" when the latter is
asked for, but not present, but the former is present.
Following this rule, 'cp /bin/sh a/bin' actually copies the file
/bin/sh.exe, so that we now have a/bin/sh.exe in the repository. This
difference did not matter in the tests in the past because we were only
interested in the equality of contents generated in various ways. But
recently added tests check file names, in particular, the presence of
"a/bin/sh". This test fails on Windows, as we do not have a file by this
name, but "a/bin/sh.exe".
Use test-genrandom to generate the large binary file in the repository
under the expected name.
We could change the guilty line to 'cat /bin/sh >a/bin/sh', but it is
better for test reproducibility to ensure that the test data is the same
across platforms, which test-genrandom can guarantee.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-24 21:29:37 +03:00
|
|
|
test-genrandom "frotz" 500000 >a/bin/sh &&
|
2007-09-14 02:13:06 +04:00
|
|
|
printf "A\$Format:%s\$O" "$SUBSTFORMAT" >a/substfile1 &&
|
|
|
|
printf "A not substituted O" >a/substfile2 &&
|
2009-03-05 00:38:24 +03:00
|
|
|
if test_have_prereq SYMLINKS; then
|
|
|
|
ln -s a a/l1
|
|
|
|
else
|
|
|
|
printf %s a > a/l1
|
|
|
|
fi &&
|
2006-03-26 01:21:07 +03:00
|
|
|
(p=long_path_to_a_file && cd a &&
|
|
|
|
for depth in 1 2 3 4 5; do mkdir $p && cd $p; done &&
|
|
|
|
echo text >file_with_long_path) &&
|
2005-06-03 00:50:17 +04:00
|
|
|
(cd a && find .) | sort >a.lst'
|
|
|
|
|
2008-06-08 20:42:33 +04:00
|
|
|
test_expect_success \
|
|
|
|
'add ignored file' \
|
|
|
|
'echo ignore me >a/ignored &&
|
2009-04-18 02:17:49 +04:00
|
|
|
echo ignored export-ignore >.git/info/attributes'
|
2008-06-08 20:42:33 +04:00
|
|
|
|
2014-07-05 23:35:01 +04:00
|
|
|
test_expect_success 'add files to repository' '
|
|
|
|
git add a &&
|
|
|
|
GIT_COMMITTER_DATE="2005-05-27 22:00" git commit -m initial
|
|
|
|
'
|
2005-06-03 00:50:17 +04:00
|
|
|
|
2013-05-20 13:58:24 +04:00
|
|
|
test_expect_success 'setup export-subst' '
|
|
|
|
echo "substfile?" export-subst >>.git/info/attributes &&
|
|
|
|
git log --max-count=1 "--pretty=format:A${SUBSTFORMAT}O" HEAD \
|
|
|
|
>a/substfile1
|
|
|
|
'
|
|
|
|
|
2008-10-25 19:38:14 +04:00
|
|
|
test_expect_success \
|
|
|
|
'create bare clone' \
|
|
|
|
'git clone --bare . bare.git &&
|
2009-04-18 02:17:49 +04:00
|
|
|
cp .git/info/attributes bare.git/info/attributes'
|
2008-10-25 19:38:14 +04:00
|
|
|
|
2008-06-08 20:42:33 +04:00
|
|
|
test_expect_success \
|
|
|
|
'remove ignored file' \
|
|
|
|
'rm a/ignored'
|
|
|
|
|
2007-04-09 19:12:53 +04:00
|
|
|
test_expect_success \
|
2007-07-03 09:52:14 +04:00
|
|
|
'git archive' \
|
|
|
|
'git archive HEAD >b.tar'
|
2007-04-09 19:12:53 +04:00
|
|
|
|
2013-05-20 13:58:26 +04:00
|
|
|
check_tar b
|
|
|
|
|
2013-05-20 13:58:27 +04:00
|
|
|
test_expect_success 'git archive --prefix=prefix/' '
|
|
|
|
git archive --prefix=prefix/ HEAD >with_prefix.tar
|
|
|
|
'
|
|
|
|
|
|
|
|
check_tar with_prefix prefix/
|
|
|
|
|
|
|
|
test_expect_success 'git-archive --prefix=olde-' '
|
|
|
|
git archive --prefix=olde- HEAD >with_olde-prefix.tar
|
|
|
|
'
|
|
|
|
|
|
|
|
check_tar with_olde-prefix olde-
|
|
|
|
|
2012-05-03 05:51:04 +04:00
|
|
|
test_expect_success 'git archive on large files' '
|
|
|
|
test_config core.bigfilethreshold 1 &&
|
|
|
|
git archive HEAD >b3.tar &&
|
2014-06-04 19:57:52 +04:00
|
|
|
test_cmp_bin b.tar b3.tar
|
2012-05-03 05:51:04 +04:00
|
|
|
'
|
|
|
|
|
2008-10-25 19:38:14 +04:00
|
|
|
test_expect_success \
|
|
|
|
'git archive in a bare repo' \
|
|
|
|
'(cd bare.git && git archive HEAD) >b3.tar'
|
|
|
|
|
|
|
|
test_expect_success \
|
|
|
|
'git archive vs. the same in a bare repo' \
|
2014-06-04 19:57:52 +04:00
|
|
|
'test_cmp_bin b.tar b3.tar'
|
2008-10-25 19:38:14 +04:00
|
|
|
|
2009-02-16 20:20:25 +03:00
|
|
|
test_expect_success 'git archive with --output' \
|
|
|
|
'git archive --output=b4.tar HEAD &&
|
2014-06-04 19:57:52 +04:00
|
|
|
test_cmp_bin b.tar b4.tar'
|
2009-02-16 20:20:25 +03:00
|
|
|
|
2011-11-19 11:40:04 +04:00
|
|
|
test_expect_success 'git archive --remote' \
|
2009-06-27 22:47:43 +04:00
|
|
|
'git archive --remote=. HEAD >b5.tar &&
|
2014-06-04 19:57:52 +04:00
|
|
|
test_cmp_bin b.tar b5.tar'
|
2009-06-27 22:47:43 +04:00
|
|
|
|
2016-11-23 00:37:04 +03:00
|
|
|
test_expect_success 'git archive --remote with configured remote' '
|
|
|
|
git config remote.foo.url . &&
|
|
|
|
(
|
|
|
|
cd a &&
|
|
|
|
git archive --remote=foo --output=../b5-nick.tar HEAD
|
|
|
|
) &&
|
|
|
|
test_cmp_bin b.tar b5-nick.tar
|
|
|
|
'
|
|
|
|
|
2005-06-03 00:50:17 +04:00
|
|
|
test_expect_success \
|
|
|
|
'validate file modification time' \
|
2008-05-13 12:45:32 +04:00
|
|
|
'mkdir extract &&
|
2008-07-25 23:35:10 +04:00
|
|
|
"$TAR" xf b.tar -C extract a/a &&
|
2008-10-30 13:20:27 +03:00
|
|
|
test-chmtime -v +0 extract/a/a |cut -f 1 >b.mtime &&
|
2008-05-13 12:45:32 +04:00
|
|
|
echo "1117231200" >expected.mtime &&
|
2009-03-16 23:18:42 +03:00
|
|
|
test_cmp expected.mtime b.mtime'
|
2005-06-03 00:50:17 +04:00
|
|
|
|
|
|
|
test_expect_success \
|
2007-07-03 09:52:14 +04:00
|
|
|
'git get-tar-commit-id' \
|
|
|
|
'git get-tar-commit-id <b.tar >b.commitid &&
|
2009-03-16 23:18:42 +03:00
|
|
|
test_cmp .git/$(git symbolic-ref HEAD) b.commitid'
|
2005-06-03 00:50:17 +04:00
|
|
|
|
2010-02-08 02:30:20 +03:00
|
|
|
test_expect_success 'git archive with --output, override inferred format' '
|
|
|
|
git archive --format=tar --output=d4.zip HEAD &&
|
2014-06-04 19:57:52 +04:00
|
|
|
test_cmp_bin b.tar d4.zip
|
2010-02-08 02:30:20 +03:00
|
|
|
'
|
|
|
|
|
2016-11-23 00:37:04 +03:00
|
|
|
test_expect_success 'git archive --list outside of a git repo' '
|
|
|
|
nongit git archive --list
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'git archive --remote outside of a git repo' '
|
|
|
|
git archive HEAD >expect.tar &&
|
|
|
|
nongit git archive --remote="$PWD" HEAD >actual.tar &&
|
|
|
|
test_cmp_bin expect.tar actual.tar
|
|
|
|
'
|
2007-04-06 00:55:43 +04:00
|
|
|
|
archive: don't let remote clients get unreachable commits
Usually git is careful not to allow clients to fetch
arbitrary objects from the database; for example, objects
received via upload-pack must be reachable from a ref.
Upload-archive breaks this by feeding the client's tree-ish
directly to get_sha1, which will accept arbitrary hex sha1s,
reflogs, etc.
This is not a problem if all of your objects are publicly
reachable anyway (or at least public to anybody who can run
upload-archive). Or if you are making the repo available by
dumb protocols like http or rsync (in which case the client
can read your whole object db directly).
But for sites which allow access only through smart
protocols, clients may be able to fetch trees from commits
that exist in the server's object database but are not
referenced (e.g., because history was rewound).
This patch tightens upload-archive's lookup to use dwim_ref
rather than get_sha1. This means a remote client can only
fetch the tip of a named ref, not an arbitrary sha1 or
reflog entry.
This also restricts some legitimate requests, too:
1. Reachable non-tip commits, like:
git archive --remote=$url v1.0~5
2. Sub-trees of reachable commits, like:
git archive --remote=$url v1.7.7:Documentation
Local requests continue to use get_sha1, and are not
restricted at all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-18 03:04:22 +04:00
|
|
|
test_expect_success 'clients cannot access unreachable commits' '
|
|
|
|
test_commit unreachable &&
|
2014-04-30 20:23:07 +04:00
|
|
|
sha1=$(git rev-parse HEAD) &&
|
archive: don't let remote clients get unreachable commits
Usually git is careful not to allow clients to fetch
arbitrary objects from the database; for example, objects
received via upload-pack must be reachable from a ref.
Upload-archive breaks this by feeding the client's tree-ish
directly to get_sha1, which will accept arbitrary hex sha1s,
reflogs, etc.
This is not a problem if all of your objects are publicly
reachable anyway (or at least public to anybody who can run
upload-archive). Or if you are making the repo available by
dumb protocols like http or rsync (in which case the client
can read your whole object db directly).
But for sites which allow access only through smart
protocols, clients may be able to fetch trees from commits
that exist in the server's object database but are not
referenced (e.g., because history was rewound).
This patch tightens upload-archive's lookup to use dwim_ref
rather than get_sha1. This means a remote client can only
fetch the tip of a named ref, not an arbitrary sha1 or
reflog entry.
This also restricts some legitimate requests, too:
1. Reachable non-tip commits, like:
git archive --remote=$url v1.0~5
2. Sub-trees of reachable commits, like:
git archive --remote=$url v1.7.7:Documentation
Local requests continue to use get_sha1, and are not
restricted at all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-18 03:04:22 +04:00
|
|
|
git reset --hard HEAD^ &&
|
|
|
|
git archive $sha1 >remote.tar &&
|
|
|
|
test_must_fail git archive --remote=. $sha1 >remote.tar
|
|
|
|
'
|
|
|
|
|
add uploadarchive.allowUnreachable option
In commit ee27ca4, we started restricting remote git-archive
invocations to only accessing reachable commits. This
matches what upload-pack allows, but does restrict some
useful cases (e.g., HEAD:foo). We loosened this in 0f544ee,
which allows `foo:bar` as long as `foo` is a ref tip.
However, that still doesn't allow many useful things, like:
1. Commits accessible from a ref, like `foo^:bar`, which
are reachable
2. Arbitrary sha1s, even if they are reachable.
We can do a full object-reachability check for these cases,
but it can be quite expensive if the client has sent us the
sha1 of a tree; we have to visit every sub-tree of every
commit in the worst case.
Let's instead give site admins an escape hatch, in case they
prefer the more liberal behavior. For many sites, the full
object database is public anyway (e.g., if you allow dumb
walker access), or the site admin may simply decide the
security/convenience tradeoff is not worth it.
This patch adds a new config option to disable the
restrictions added in ee27ca4. It defaults to off, meaning
there is no change in behavior by default.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-28 14:04:19 +04:00
|
|
|
test_expect_success 'upload-archive can allow unreachable commits' '
|
|
|
|
test_commit unreachable1 &&
|
2014-04-30 20:23:07 +04:00
|
|
|
sha1=$(git rev-parse HEAD) &&
|
add uploadarchive.allowUnreachable option
In commit ee27ca4, we started restricting remote git-archive
invocations to only accessing reachable commits. This
matches what upload-pack allows, but does restrict some
useful cases (e.g., HEAD:foo). We loosened this in 0f544ee,
which allows `foo:bar` as long as `foo` is a ref tip.
However, that still doesn't allow many useful things, like:
1. Commits accessible from a ref, like `foo^:bar`, which
are reachable
2. Arbitrary sha1s, even if they are reachable.
We can do a full object-reachability check for these cases,
but it can be quite expensive if the client has sent us the
sha1 of a tree; we have to visit every sub-tree of every
commit in the worst case.
Let's instead give site admins an escape hatch, in case they
prefer the more liberal behavior. For many sites, the full
object database is public anyway (e.g., if you allow dumb
walker access), or the site admin may simply decide the
security/convenience tradeoff is not worth it.
This patch adds a new config option to disable the
restrictions added in ee27ca4. It defaults to off, meaning
there is no change in behavior by default.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-28 14:04:19 +04:00
|
|
|
git reset --hard HEAD^ &&
|
|
|
|
git archive $sha1 >remote.tar &&
|
|
|
|
test_config uploadarchive.allowUnreachable true &&
|
|
|
|
git archive --remote=. $sha1 >remote.tar
|
|
|
|
'
|
|
|
|
|
2011-06-22 05:26:31 +04:00
|
|
|
test_expect_success 'setup tar filters' '
|
|
|
|
git config tar.tar.foo.command "tr ab ba" &&
|
2011-06-22 07:17:35 +04:00
|
|
|
git config tar.bar.command "tr ab ba" &&
|
2013-01-23 10:23:27 +04:00
|
|
|
git config tar.bar.remote true &&
|
|
|
|
git config tar.invalid baz
|
2011-06-22 05:26:31 +04:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'archive --list mentions user filter' '
|
|
|
|
git archive --list >output &&
|
|
|
|
grep "^tar\.foo\$" output &&
|
|
|
|
grep "^bar\$" output
|
|
|
|
'
|
|
|
|
|
2011-11-19 11:40:04 +04:00
|
|
|
test_expect_success 'archive --list shows only enabled remote filters' '
|
2011-06-22 05:26:31 +04:00
|
|
|
git archive --list --remote=. >output &&
|
2011-06-22 07:17:35 +04:00
|
|
|
! grep "^tar\.foo\$" output &&
|
2011-06-22 05:26:31 +04:00
|
|
|
grep "^bar\$" output
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'invoke tar filter by format' '
|
|
|
|
git archive --format=tar.foo HEAD >config.tar.foo &&
|
|
|
|
tr ab ba <config.tar.foo >config.tar &&
|
2014-06-04 19:57:52 +04:00
|
|
|
test_cmp_bin b.tar config.tar &&
|
2011-06-22 05:26:31 +04:00
|
|
|
git archive --format=bar HEAD >config.bar &&
|
|
|
|
tr ab ba <config.bar >config.tar &&
|
2014-06-04 19:57:52 +04:00
|
|
|
test_cmp_bin b.tar config.tar
|
2011-06-22 05:26:31 +04:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'invoke tar filter by extension' '
|
|
|
|
git archive -o config-implicit.tar.foo HEAD &&
|
2014-06-04 19:57:52 +04:00
|
|
|
test_cmp_bin config.tar.foo config-implicit.tar.foo &&
|
2011-06-22 05:26:31 +04:00
|
|
|
git archive -o config-implicit.bar HEAD &&
|
2014-06-04 19:57:52 +04:00
|
|
|
test_cmp_bin config.tar.foo config-implicit.bar
|
2011-06-22 05:26:31 +04:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'default output format remains tar' '
|
|
|
|
git archive -o config-implicit.baz HEAD &&
|
2014-06-04 19:57:52 +04:00
|
|
|
test_cmp_bin b.tar config-implicit.baz
|
2011-06-22 05:26:31 +04:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'extension matching requires dot' '
|
|
|
|
git archive -o config-implicittar.foo HEAD &&
|
2014-06-04 19:57:52 +04:00
|
|
|
test_cmp_bin b.tar config-implicittar.foo
|
2011-06-22 05:26:31 +04:00
|
|
|
'
|
|
|
|
|
2011-11-19 11:40:04 +04:00
|
|
|
test_expect_success 'only enabled filters are available remotely' '
|
2011-06-22 07:17:35 +04:00
|
|
|
test_must_fail git archive --remote=. --format=tar.foo HEAD \
|
|
|
|
>remote.tar.foo &&
|
|
|
|
git archive --remote=. --format=bar >remote.bar HEAD &&
|
2014-06-04 19:57:52 +04:00
|
|
|
test_cmp_bin remote.bar config.bar
|
2011-06-22 07:17:35 +04:00
|
|
|
'
|
|
|
|
|
2011-06-22 05:27:35 +04:00
|
|
|
test_expect_success GZIP 'git archive --format=tgz' '
|
|
|
|
git archive --format=tgz HEAD >j.tgz
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success GZIP 'git archive --format=tar.gz' '
|
|
|
|
git archive --format=tar.gz HEAD >j1.tar.gz &&
|
2014-06-04 19:57:52 +04:00
|
|
|
test_cmp_bin j.tgz j1.tar.gz
|
2011-06-22 05:27:35 +04:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success GZIP 'infer tgz from .tgz filename' '
|
|
|
|
git archive --output=j2.tgz HEAD &&
|
2014-06-04 19:57:52 +04:00
|
|
|
test_cmp_bin j.tgz j2.tgz
|
2011-06-22 05:27:35 +04:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success GZIP 'infer tgz from .tar.gz filename' '
|
|
|
|
git archive --output=j3.tar.gz HEAD &&
|
2014-06-04 19:57:52 +04:00
|
|
|
test_cmp_bin j.tgz j3.tar.gz
|
2011-06-22 05:27:35 +04:00
|
|
|
'
|
|
|
|
|
t5000: simplify gzip prerequisite checks
In t5000, we test the built-in ".tar.gz" config for
git-archive. To make our tests portable, we check that we
have a way to both gzip and gunzip, and we respected
environment variables to point to alternate commands for
doing these operations.
However, the $GZIP variable did not actually do anything, as
changing it would not affect the baked-in value in
archive-tar.c. Moreover, setting the variable $GZIP
influences gzip itself. From the gzip man page:
The environment variable GZIP can hold a set of default
options for gzip. These options are interpreted first and
can be overwritten by explicit command line parameters.
We could rename this variable, and use it to set up custom
config (or even have a Makefile knob to affect the built
binary), but it is not worth the trouble; nobody has ever
reported a problem with the baked-in default, and they can
always change it via config if they need to. Let's just drop
the variable and use "gzip" in the test (keeping the
prerequisite, of course).
While we're at it, we can drop the GUNZIP variable and
prerequisite; it uses "gzip -d", so if we have GZIP, we
will have both.
We can also use test_lazy_prereq for the gzip prerequisite,
which is simpler and behaves more consistently with the rest
of git (e.g., by making output available when the test is
run with "-v").
Noticed-by: Christian Hesse <mail@eworm.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-03 17:21:40 +04:00
|
|
|
test_expect_success GZIP 'extract tgz file' '
|
|
|
|
gzip -d -c <j.tgz >j.tar &&
|
2014-06-04 19:57:52 +04:00
|
|
|
test_cmp_bin b.tar j.tar
|
2011-06-22 05:27:35 +04:00
|
|
|
'
|
|
|
|
|
2011-11-19 11:40:04 +04:00
|
|
|
test_expect_success GZIP 'remote tar.gz is allowed by default' '
|
2011-06-22 07:17:35 +04:00
|
|
|
git archive --remote=. --format=tar.gz HEAD >remote.tar.gz &&
|
2014-06-04 19:57:52 +04:00
|
|
|
test_cmp_bin j.tgz remote.tar.gz
|
2011-06-22 07:17:35 +04:00
|
|
|
'
|
|
|
|
|
2011-11-19 11:40:04 +04:00
|
|
|
test_expect_success GZIP 'remote tar.gz can be disabled' '
|
2011-06-22 07:17:35 +04:00
|
|
|
git config tar.tar.gz.remote false &&
|
|
|
|
test_must_fail git archive --remote=. --format=tar.gz HEAD \
|
|
|
|
>remote.tar.gz
|
|
|
|
'
|
|
|
|
|
2014-09-21 07:55:06 +04:00
|
|
|
test_expect_success 'archive and :(glob)' '
|
|
|
|
git archive -v HEAD -- ":(glob)**/sh" >/dev/null 2>actual &&
|
|
|
|
cat >expect <<EOF &&
|
|
|
|
a/
|
|
|
|
a/bin/
|
|
|
|
a/bin/sh
|
|
|
|
EOF
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'catch non-matching pathspec' '
|
|
|
|
test_must_fail git archive -v HEAD -- "*.abc" >/dev/null
|
|
|
|
'
|
|
|
|
|
t5000: test tar files that overflow ustar headers
The ustar format only has room for 11 (or 12, depending on
some implementations) octal digits for the size and mtime of
each file. For values larger than this, we have to add pax
extended headers to specify the real data, and git does not
yet know how to do so.
Before fixing that, let's start off with some test
infrastructure, as designing portable and efficient tests
for this is non-trivial.
We want to use the system tar to check our output (because
what we really care about is interoperability), but we can't
rely on it:
1. being able to read pax headers
2. being able to handle huge sizes or mtimes
3. supporting a "t" format we can parse
So as a prerequisite, we can feed the system tar a reference
tarball to make sure it can handle these features. The
reference tar here was created with:
dd if=/dev/zero seek=64G bs=1 count=1 of=huge
touch -d @68719476737 huge
tar cf - --format=pax |
head -c 2048
using GNU tar. Note that this is not a complete tarfile, but
it's enough to contain the headers we want to examine.
Likewise, we need to convince git that it has a 64GB blob to
output. Running "git add" on that 64GB file takes many
minutes of CPU, and even compressed, the result is 64MB. So
again, I pre-generated that loose object, and then took only
the first 2k of it. That should be enough to generate 2MB of
data before hitting an inflate error, which is plenty for us
to generate the tar header (and then die of SIGPIPE while
streaming the rest out).
The tests are split so that we test as much as we can even
with an uncooperative system tar. This actually catches the
current breakage (which is that we die("BUG") trying to
write the ustar header) on every system, and then on systems
where we can, we go farther and actually verify the result.
Helped-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 12:08:57 +03:00
|
|
|
# Pull the size and date of each entry in a tarfile using the system tar.
|
|
|
|
#
|
|
|
|
# We'll pull out only the year from the date; that avoids any question of
|
|
|
|
# timezones impacting the result (as long as we keep our test times away from a
|
|
|
|
# year boundary; our reference times are all in August).
|
|
|
|
#
|
|
|
|
# The output of tar_info is expected to be "<size> <year>", both in decimal. It
|
|
|
|
# ignores the return value of tar. We have to do this, because some of our test
|
|
|
|
# input is only partial (the real data is 64GB in some cases).
|
|
|
|
tar_info () {
|
|
|
|
"$TAR" tvf "$1" |
|
|
|
|
awk '{
|
|
|
|
split($4, date, "-")
|
|
|
|
print $3 " " date[1]
|
|
|
|
}'
|
|
|
|
}
|
|
|
|
|
|
|
|
# See if our system tar can handle a tar file with huge sizes and dates far in
|
|
|
|
# the future, and that we can actually parse its output.
|
|
|
|
#
|
|
|
|
# The reference file was generated by GNU tar, and the magic time and size are
|
|
|
|
# both octal 01000000000001, which overflows normal ustar fields.
|
|
|
|
test_lazy_prereq TAR_HUGE '
|
|
|
|
echo "68719476737 4147" >expect &&
|
|
|
|
tar_info "$TEST_DIRECTORY"/t5000/huge-and-future.tar >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2016-07-14 23:04:43 +03:00
|
|
|
test_expect_success LONG_IS_64BIT 'set up repository with huge blob' '
|
t5000: test tar files that overflow ustar headers
The ustar format only has room for 11 (or 12, depending on
some implementations) octal digits for the size and mtime of
each file. For values larger than this, we have to add pax
extended headers to specify the real data, and git does not
yet know how to do so.
Before fixing that, let's start off with some test
infrastructure, as designing portable and efficient tests
for this is non-trivial.
We want to use the system tar to check our output (because
what we really care about is interoperability), but we can't
rely on it:
1. being able to read pax headers
2. being able to handle huge sizes or mtimes
3. supporting a "t" format we can parse
So as a prerequisite, we can feed the system tar a reference
tarball to make sure it can handle these features. The
reference tar here was created with:
dd if=/dev/zero seek=64G bs=1 count=1 of=huge
touch -d @68719476737 huge
tar cf - --format=pax |
head -c 2048
using GNU tar. Note that this is not a complete tarfile, but
it's enough to contain the headers we want to examine.
Likewise, we need to convince git that it has a 64GB blob to
output. Running "git add" on that 64GB file takes many
minutes of CPU, and even compressed, the result is 64MB. So
again, I pre-generated that loose object, and then took only
the first 2k of it. That should be enough to generate 2MB of
data before hitting an inflate error, which is plenty for us
to generate the tar header (and then die of SIGPIPE while
streaming the rest out).
The tests are split so that we test as much as we can even
with an uncooperative system tar. This actually catches the
current breakage (which is that we die("BUG") trying to
write the ustar header) on every system, and then on systems
where we can, we go farther and actually verify the result.
Helped-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 12:08:57 +03:00
|
|
|
obj_d=19 &&
|
|
|
|
obj_f=f9c8273ec45a8938e6999cb59b3ff66739902a &&
|
|
|
|
obj=${obj_d}${obj_f} &&
|
|
|
|
mkdir -p .git/objects/$obj_d &&
|
|
|
|
cp "$TEST_DIRECTORY"/t5000/$obj .git/objects/$obj_d/$obj_f &&
|
|
|
|
rm -f .git/index &&
|
|
|
|
git update-index --add --cacheinfo 100644,$obj,huge &&
|
|
|
|
git commit -m huge
|
|
|
|
'
|
|
|
|
|
|
|
|
# We expect git to die with SIGPIPE here (otherwise we
|
|
|
|
# would generate the whole 64GB).
|
2016-07-14 23:04:43 +03:00
|
|
|
test_expect_success LONG_IS_64BIT 'generate tar with huge size' '
|
t5000: test tar files that overflow ustar headers
The ustar format only has room for 11 (or 12, depending on
some implementations) octal digits for the size and mtime of
each file. For values larger than this, we have to add pax
extended headers to specify the real data, and git does not
yet know how to do so.
Before fixing that, let's start off with some test
infrastructure, as designing portable and efficient tests
for this is non-trivial.
We want to use the system tar to check our output (because
what we really care about is interoperability), but we can't
rely on it:
1. being able to read pax headers
2. being able to handle huge sizes or mtimes
3. supporting a "t" format we can parse
So as a prerequisite, we can feed the system tar a reference
tarball to make sure it can handle these features. The
reference tar here was created with:
dd if=/dev/zero seek=64G bs=1 count=1 of=huge
touch -d @68719476737 huge
tar cf - --format=pax |
head -c 2048
using GNU tar. Note that this is not a complete tarfile, but
it's enough to contain the headers we want to examine.
Likewise, we need to convince git that it has a 64GB blob to
output. Running "git add" on that 64GB file takes many
minutes of CPU, and even compressed, the result is 64MB. So
again, I pre-generated that loose object, and then took only
the first 2k of it. That should be enough to generate 2MB of
data before hitting an inflate error, which is plenty for us
to generate the tar header (and then die of SIGPIPE while
streaming the rest out).
The tests are split so that we test as much as we can even
with an uncooperative system tar. This actually catches the
current breakage (which is that we die("BUG") trying to
write the ustar header) on every system, and then on systems
where we can, we go farther and actually verify the result.
Helped-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 12:08:57 +03:00
|
|
|
{
|
|
|
|
git archive HEAD
|
|
|
|
echo $? >exit-code
|
|
|
|
} | test_copy_bytes 4096 >huge.tar &&
|
|
|
|
echo 141 >expect &&
|
|
|
|
test_cmp expect exit-code
|
|
|
|
'
|
|
|
|
|
2016-07-14 23:04:43 +03:00
|
|
|
test_expect_success TAR_HUGE,LONG_IS_64BIT 'system tar can read our huge size' '
|
t5000: test tar files that overflow ustar headers
The ustar format only has room for 11 (or 12, depending on
some implementations) octal digits for the size and mtime of
each file. For values larger than this, we have to add pax
extended headers to specify the real data, and git does not
yet know how to do so.
Before fixing that, let's start off with some test
infrastructure, as designing portable and efficient tests
for this is non-trivial.
We want to use the system tar to check our output (because
what we really care about is interoperability), but we can't
rely on it:
1. being able to read pax headers
2. being able to handle huge sizes or mtimes
3. supporting a "t" format we can parse
So as a prerequisite, we can feed the system tar a reference
tarball to make sure it can handle these features. The
reference tar here was created with:
dd if=/dev/zero seek=64G bs=1 count=1 of=huge
touch -d @68719476737 huge
tar cf - --format=pax |
head -c 2048
using GNU tar. Note that this is not a complete tarfile, but
it's enough to contain the headers we want to examine.
Likewise, we need to convince git that it has a 64GB blob to
output. Running "git add" on that 64GB file takes many
minutes of CPU, and even compressed, the result is 64MB. So
again, I pre-generated that loose object, and then took only
the first 2k of it. That should be enough to generate 2MB of
data before hitting an inflate error, which is plenty for us
to generate the tar header (and then die of SIGPIPE while
streaming the rest out).
The tests are split so that we test as much as we can even
with an uncooperative system tar. This actually catches the
current breakage (which is that we die("BUG") trying to
write the ustar header) on every system, and then on systems
where we can, we go farther and actually verify the result.
Helped-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 12:08:57 +03:00
|
|
|
echo 68719476737 >expect &&
|
|
|
|
tar_info huge.tar | cut -d" " -f1 >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
t0006 & t5000: prepare for 64-bit timestamps
Git's source code refers to timestamps as unsigned longs. On 32-bit
platforms, as well as on Windows, unsigned long is not large enough to
capture dates that are "absurdly far in the future".
It is perfectly valid by the C standard, of course, for the `long` data
type to refer to 32-bit integers. That is why the `time_t` data type
exists: so that it can be 64-bit even if `long` is 32-bit. Git's source
code simply uses an incorrect data type for timestamps, is all.
The earlier quick fix 6b9c38e14cd (t0006: skip "far in the future" test
when unsigned long is not long enough, 2016-07-11) papered over this
issue simply by skipping the respective test cases on platforms where
they would fail due to the data type in use.
This quick fix, however, tests for *long* to be 64-bit or not. What we
need, though, is a test that says whether *whatever data type we use for
timestamps* is 64-bit or not.
The same quick fix was used to handle the similar problem where Git's
source code uses `unsigned long` to represent size, instead of `size_t`,
conflating the two issues.
So let's just add another prerequisite to test specifically whether
timestamps are represented by a 64-bit data type or not. Later, after we
switch to a larger data type, we can flip that prerequisite to test
`time_t` instead of `long`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-20 23:52:13 +03:00
|
|
|
test_expect_success TIME_IS_64BIT 'set up repository with far-future commit' '
|
t5000: test tar files that overflow ustar headers
The ustar format only has room for 11 (or 12, depending on
some implementations) octal digits for the size and mtime of
each file. For values larger than this, we have to add pax
extended headers to specify the real data, and git does not
yet know how to do so.
Before fixing that, let's start off with some test
infrastructure, as designing portable and efficient tests
for this is non-trivial.
We want to use the system tar to check our output (because
what we really care about is interoperability), but we can't
rely on it:
1. being able to read pax headers
2. being able to handle huge sizes or mtimes
3. supporting a "t" format we can parse
So as a prerequisite, we can feed the system tar a reference
tarball to make sure it can handle these features. The
reference tar here was created with:
dd if=/dev/zero seek=64G bs=1 count=1 of=huge
touch -d @68719476737 huge
tar cf - --format=pax |
head -c 2048
using GNU tar. Note that this is not a complete tarfile, but
it's enough to contain the headers we want to examine.
Likewise, we need to convince git that it has a 64GB blob to
output. Running "git add" on that 64GB file takes many
minutes of CPU, and even compressed, the result is 64MB. So
again, I pre-generated that loose object, and then took only
the first 2k of it. That should be enough to generate 2MB of
data before hitting an inflate error, which is plenty for us
to generate the tar header (and then die of SIGPIPE while
streaming the rest out).
The tests are split so that we test as much as we can even
with an uncooperative system tar. This actually catches the
current breakage (which is that we die("BUG") trying to
write the ustar header) on every system, and then on systems
where we can, we go farther and actually verify the result.
Helped-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 12:08:57 +03:00
|
|
|
rm -f .git/index &&
|
|
|
|
echo content >file &&
|
|
|
|
git add file &&
|
|
|
|
GIT_COMMITTER_DATE="@68719476737 +0000" \
|
|
|
|
git commit -m "tempori parendum"
|
|
|
|
'
|
|
|
|
|
t0006 & t5000: prepare for 64-bit timestamps
Git's source code refers to timestamps as unsigned longs. On 32-bit
platforms, as well as on Windows, unsigned long is not large enough to
capture dates that are "absurdly far in the future".
It is perfectly valid by the C standard, of course, for the `long` data
type to refer to 32-bit integers. That is why the `time_t` data type
exists: so that it can be 64-bit even if `long` is 32-bit. Git's source
code simply uses an incorrect data type for timestamps, is all.
The earlier quick fix 6b9c38e14cd (t0006: skip "far in the future" test
when unsigned long is not long enough, 2016-07-11) papered over this
issue simply by skipping the respective test cases on platforms where
they would fail due to the data type in use.
This quick fix, however, tests for *long* to be 64-bit or not. What we
need, though, is a test that says whether *whatever data type we use for
timestamps* is 64-bit or not.
The same quick fix was used to handle the similar problem where Git's
source code uses `unsigned long` to represent size, instead of `size_t`,
conflating the two issues.
So let's just add another prerequisite to test specifically whether
timestamps are represented by a 64-bit data type or not. Later, after we
switch to a larger data type, we can flip that prerequisite to test
`time_t` instead of `long`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-20 23:52:13 +03:00
|
|
|
test_expect_success TIME_IS_64BIT 'generate tar with future mtime' '
|
t5000: test tar files that overflow ustar headers
The ustar format only has room for 11 (or 12, depending on
some implementations) octal digits for the size and mtime of
each file. For values larger than this, we have to add pax
extended headers to specify the real data, and git does not
yet know how to do so.
Before fixing that, let's start off with some test
infrastructure, as designing portable and efficient tests
for this is non-trivial.
We want to use the system tar to check our output (because
what we really care about is interoperability), but we can't
rely on it:
1. being able to read pax headers
2. being able to handle huge sizes or mtimes
3. supporting a "t" format we can parse
So as a prerequisite, we can feed the system tar a reference
tarball to make sure it can handle these features. The
reference tar here was created with:
dd if=/dev/zero seek=64G bs=1 count=1 of=huge
touch -d @68719476737 huge
tar cf - --format=pax |
head -c 2048
using GNU tar. Note that this is not a complete tarfile, but
it's enough to contain the headers we want to examine.
Likewise, we need to convince git that it has a 64GB blob to
output. Running "git add" on that 64GB file takes many
minutes of CPU, and even compressed, the result is 64MB. So
again, I pre-generated that loose object, and then took only
the first 2k of it. That should be enough to generate 2MB of
data before hitting an inflate error, which is plenty for us
to generate the tar header (and then die of SIGPIPE while
streaming the rest out).
The tests are split so that we test as much as we can even
with an uncooperative system tar. This actually catches the
current breakage (which is that we die("BUG") trying to
write the ustar header) on every system, and then on systems
where we can, we go farther and actually verify the result.
Helped-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 12:08:57 +03:00
|
|
|
git archive HEAD >future.tar
|
|
|
|
'
|
|
|
|
|
t0006 & t5000: prepare for 64-bit timestamps
Git's source code refers to timestamps as unsigned longs. On 32-bit
platforms, as well as on Windows, unsigned long is not large enough to
capture dates that are "absurdly far in the future".
It is perfectly valid by the C standard, of course, for the `long` data
type to refer to 32-bit integers. That is why the `time_t` data type
exists: so that it can be 64-bit even if `long` is 32-bit. Git's source
code simply uses an incorrect data type for timestamps, is all.
The earlier quick fix 6b9c38e14cd (t0006: skip "far in the future" test
when unsigned long is not long enough, 2016-07-11) papered over this
issue simply by skipping the respective test cases on platforms where
they would fail due to the data type in use.
This quick fix, however, tests for *long* to be 64-bit or not. What we
need, though, is a test that says whether *whatever data type we use for
timestamps* is 64-bit or not.
The same quick fix was used to handle the similar problem where Git's
source code uses `unsigned long` to represent size, instead of `size_t`,
conflating the two issues.
So let's just add another prerequisite to test specifically whether
timestamps are represented by a 64-bit data type or not. Later, after we
switch to a larger data type, we can flip that prerequisite to test
`time_t` instead of `long`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-20 23:52:13 +03:00
|
|
|
test_expect_success TAR_HUGE,TIME_IS_64BIT 'system tar can read our future mtime' '
|
t5000: test tar files that overflow ustar headers
The ustar format only has room for 11 (or 12, depending on
some implementations) octal digits for the size and mtime of
each file. For values larger than this, we have to add pax
extended headers to specify the real data, and git does not
yet know how to do so.
Before fixing that, let's start off with some test
infrastructure, as designing portable and efficient tests
for this is non-trivial.
We want to use the system tar to check our output (because
what we really care about is interoperability), but we can't
rely on it:
1. being able to read pax headers
2. being able to handle huge sizes or mtimes
3. supporting a "t" format we can parse
So as a prerequisite, we can feed the system tar a reference
tarball to make sure it can handle these features. The
reference tar here was created with:
dd if=/dev/zero seek=64G bs=1 count=1 of=huge
touch -d @68719476737 huge
tar cf - --format=pax |
head -c 2048
using GNU tar. Note that this is not a complete tarfile, but
it's enough to contain the headers we want to examine.
Likewise, we need to convince git that it has a 64GB blob to
output. Running "git add" on that 64GB file takes many
minutes of CPU, and even compressed, the result is 64MB. So
again, I pre-generated that loose object, and then took only
the first 2k of it. That should be enough to generate 2MB of
data before hitting an inflate error, which is plenty for us
to generate the tar header (and then die of SIGPIPE while
streaming the rest out).
The tests are split so that we test as much as we can even
with an uncooperative system tar. This actually catches the
current breakage (which is that we die("BUG") trying to
write the ustar header) on every system, and then on systems
where we can, we go farther and actually verify the result.
Helped-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-30 12:08:57 +03:00
|
|
|
echo 4147 >expect &&
|
|
|
|
tar_info future.tar | cut -d" " -f2 >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2005-06-03 00:50:17 +04:00
|
|
|
test_done
|