git/t/t5607-clone-bundle.sh

173 lines
4.3 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='some bundle related tests'
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
tests: mark tests relying on the current default for `init.defaultBranch` In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-18 23:44:19 +00:00
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
. ./test-lib.sh
test_expect_success 'setup' '
test_oid_cache <<-EOF &&
version sha1:2
version sha256:3
EOF
test_commit initial &&
test_tick &&
git tag -m tag tag &&
test_commit second &&
test_commit third &&
git tag -d initial &&
git tag -d second &&
git tag -d third
'
test_expect_success '"verify" needs a worktree' '
git bundle create tip.bundle -1 main &&
nongit test_must_fail git bundle verify ../tip.bundle 2>err &&
test_i18ngrep "need a repository" err
'
test_expect_success 'annotated tags can be excluded by rev-list options' '
git bundle create bundle --all --since=7.Apr.2005.15:14:00.-0700 &&
cat >expect <<-EOF &&
$(git rev-parse HEAD) HEAD
$(git rev-parse tag) refs/tags/tag
$(git rev-parse main) refs/heads/main
EOF
git ls-remote bundle >actual &&
test_cmp expect actual &&
git bundle create bundle --all --since=7.Apr.2005.15:16:00.-0700 &&
cat >expect <<-EOF &&
$(git rev-parse HEAD) HEAD
$(git rev-parse main) refs/heads/main
EOF
git ls-remote bundle >actual &&
test_cmp expect actual
'
test_expect_success 'die if bundle file cannot be created' '
mkdir adir &&
test_must_fail git bundle create adir --all
'
bundle: arguments can be read from stdin In order to create an incremental bundle, we need to pass many arguments to let git-bundle ignore some already packed commits. It will be more convenient to pass args via stdin. But the current implementation does not allow us to do this. This is because args are parsed twice when creating bundle. The first time for parsing args is in `compute_and_write_prerequisites()` by running `git-rev-list` command to write prerequisites in bundle file, and stdin is consumed in this step if "--stdin" option is provided for `git-bundle`. Later nothing can be read from stdin when running `setup_revisions()` in `create_bundle()`. The solution is to parse args once by removing the entire function `compute_and_write_prerequisites()` and then calling function `setup_revisions()`. In order to write prerequisites for bundle, will call `prepare_revision_walk()` and `traverse_commit_list()`. But after calling `prepare_revision_walk()`, the object array `revs.pending` is left empty, and the following steps could not work properly with the empty object array (`revs.pending`). Therefore, make a copy of `revs` to `revs_copy` for later use right after calling `setup_revisions()`. The copy of `revs_copy` is not a deep copy, it shares the same objects with `revs`. The object array of `revs` has been cleared, but objects themselves are still kept. Flags of objects may change after calling `prepare_revision_walk()`, we can use these changed flags without calling the `git rev-list` command and parsing its output like the former implementation. Also add testcases for git bundle in t6020, which read args from stdin. Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-12 02:27:03 +00:00
test_expect_success 'bundle --stdin' '
echo main | git bundle create stdin-bundle.bdl --stdin &&
cat >expect <<-EOF &&
$(git rev-parse main) refs/heads/main
EOF
git ls-remote stdin-bundle.bdl >actual &&
test_cmp expect actual
'
bundle: arguments can be read from stdin In order to create an incremental bundle, we need to pass many arguments to let git-bundle ignore some already packed commits. It will be more convenient to pass args via stdin. But the current implementation does not allow us to do this. This is because args are parsed twice when creating bundle. The first time for parsing args is in `compute_and_write_prerequisites()` by running `git-rev-list` command to write prerequisites in bundle file, and stdin is consumed in this step if "--stdin" option is provided for `git-bundle`. Later nothing can be read from stdin when running `setup_revisions()` in `create_bundle()`. The solution is to parse args once by removing the entire function `compute_and_write_prerequisites()` and then calling function `setup_revisions()`. In order to write prerequisites for bundle, will call `prepare_revision_walk()` and `traverse_commit_list()`. But after calling `prepare_revision_walk()`, the object array `revs.pending` is left empty, and the following steps could not work properly with the empty object array (`revs.pending`). Therefore, make a copy of `revs` to `revs_copy` for later use right after calling `setup_revisions()`. The copy of `revs_copy` is not a deep copy, it shares the same objects with `revs`. The object array of `revs` has been cleared, but objects themselves are still kept. Flags of objects may change after calling `prepare_revision_walk()`, we can use these changed flags without calling the `git rev-list` command and parsing its output like the former implementation. Also add testcases for git bundle in t6020, which read args from stdin. Signed-off-by: Jiang Xin <zhiyou.jx@alibaba-inc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-12 02:27:03 +00:00
test_expect_success 'bundle --stdin <rev-list options>' '
echo main | git bundle create hybrid-bundle.bdl --stdin tag &&
cat >expect <<-EOF &&
$(git rev-parse main) refs/heads/main
EOF
git ls-remote stdin-bundle.bdl >actual &&
test_cmp expect actual
'
test_expect_success 'empty bundle file is rejected' '
>empty-bundle &&
test_must_fail git fetch empty-bundle
'
# This triggers a bug in older versions where the resulting line (with
# --pretty=oneline) was longer than a 1024-char buffer.
test_expect_success 'ridiculously long subject in boundary' '
>file4 &&
test_tick &&
git add file4 &&
printf "%01200d\n" 0 | git commit -F - &&
test_commit fifth &&
git bundle create long-subject-bundle.bdl HEAD^..HEAD &&
cat >expect <<-EOF &&
$(git rev-parse main) HEAD
EOF
git bundle list-heads long-subject-bundle.bdl >actual &&
test_cmp expect actual &&
git fetch long-subject-bundle.bdl &&
algo=$(test_oid algo) &&
if test "$algo" != sha1
then
echo "@object-format=sha256"
fi >expect &&
cat >>expect <<-EOF &&
-$(git log --pretty=format:"%H %s" -1 HEAD^)
$(git rev-parse HEAD) HEAD
EOF
if test "$algo" = sha1
then
head -n 3 long-subject-bundle.bdl
else
head -n 4 long-subject-bundle.bdl
fi | grep -v "^#" >actual &&
test_cmp expect actual
'
test_expect_success 'prerequisites with an empty commit message' '
>file1 &&
git add file1 &&
test_tick &&
git commit --allow-empty-message -m "" &&
test_commit file2 &&
git bundle create bundle HEAD^.. &&
git bundle verify bundle
'
bundle: dup() output descriptor closer to point-of-use When writing a bundle to a file, the bundle code actually creates "your.bundle.lock" using our lockfile interface. We feed that output descriptor to a child git-pack-objects via run-command, which has the quirk that it closes the output descriptor in the parent. To avoid confusing the lockfile code (which still thinks the descriptor is valid), we dup() it, and operate on the duplicate. However, this has a confusing side effect: after the dup() but before we call pack-objects, we have _two_ descriptors open to the lockfile. If we call die() during that time, the lockfile code will try to clean up the partially-written file. It knows to close() the file before unlinking, since on some platforms (i.e., Windows) the open file would block the deletion. But it doesn't know about the duplicate descriptor. On Windows, triggering an error at the right part of the code will result in the cleanup failing and the lockfile being left in the filesystem. We can solve this by moving the dup() much closer to start_command(), shrinking the window in which we have the second descriptor open. It's easy to place this in such a way that no die() is possible. We could still die due to a signal in the exact wrong moment, but we already tolerate races there (e.g., a signal could come before we manage to put the file on the cleanup list in the first place). As a bonus, this shields create_bundle() itself from the duplicate-fd trick, and we can simplify its error handling (note that the lock rollback now happens unconditionally, but that's OK; it's a noop if we didn't open the lock in the first place). The included test uses an empty bundle to cause a failure at the right spot in the code, because that's easy to trigger (the other likely errors are write() problems like ENOSPC). Note that it would already pass on non-Windows systems (because they are happy to unlink an already-open file). Based-on-a-patch-by: Gaël Lhez <gael.lhez@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Tested-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16 09:43:59 +00:00
test_expect_success 'failed bundle creation does not leave cruft' '
# This fails because the bundle would be empty.
test_must_fail git bundle create fail.bundle main..main &&
bundle: dup() output descriptor closer to point-of-use When writing a bundle to a file, the bundle code actually creates "your.bundle.lock" using our lockfile interface. We feed that output descriptor to a child git-pack-objects via run-command, which has the quirk that it closes the output descriptor in the parent. To avoid confusing the lockfile code (which still thinks the descriptor is valid), we dup() it, and operate on the duplicate. However, this has a confusing side effect: after the dup() but before we call pack-objects, we have _two_ descriptors open to the lockfile. If we call die() during that time, the lockfile code will try to clean up the partially-written file. It knows to close() the file before unlinking, since on some platforms (i.e., Windows) the open file would block the deletion. But it doesn't know about the duplicate descriptor. On Windows, triggering an error at the right part of the code will result in the cleanup failing and the lockfile being left in the filesystem. We can solve this by moving the dup() much closer to start_command(), shrinking the window in which we have the second descriptor open. It's easy to place this in such a way that no die() is possible. We could still die due to a signal in the exact wrong moment, but we already tolerate races there (e.g., a signal could come before we manage to put the file on the cleanup list in the first place). As a bonus, this shields create_bundle() itself from the duplicate-fd trick, and we can simplify its error handling (note that the lock rollback now happens unconditionally, but that's OK; it's a noop if we didn't open the lock in the first place). The included test uses an empty bundle to cause a failure at the right spot in the code, because that's easy to trigger (the other likely errors are write() problems like ENOSPC). Note that it would already pass on non-Windows systems (because they are happy to unlink an already-open file). Based-on-a-patch-by: Gaël Lhez <gael.lhez@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Tested-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-16 09:43:59 +00:00
test_path_is_missing fail.bundle.lock
'
test_expect_success 'fetch SHA-1 from bundle' '
test_create_repo foo &&
test_commit -C foo x &&
git -C foo bundle create tip.bundle -1 main &&
git -C foo rev-parse HEAD >hash &&
# Exercise to ensure that fetching a SHA-1 from a bundle works with no
# errors
git fetch --no-tags foo/tip.bundle "$(cat hash)"
'
test_expect_success 'git bundle uses expected default format' '
git bundle create bundle HEAD^.. &&
cat >expect <<-EOF &&
# v$(test_oid version) git bundle
EOF
head -n1 bundle >actual &&
test_cmp expect actual
'
test_expect_success 'git bundle v3 has expected contents' '
git branch side HEAD &&
git bundle create --version=3 bundle HEAD^..side &&
head -n2 bundle >actual &&
cat >expect <<-EOF &&
# v3 git bundle
@object-format=$(test_oid algo)
EOF
test_cmp expect actual &&
git bundle verify bundle
'
test_expect_success 'git bundle v3 rejects unknown capabilities' '
cat >new <<-EOF &&
# v3 git bundle
@object-format=$(test_oid algo)
@unknown=silly
EOF
test_must_fail git bundle verify new 2>output &&
test_i18ngrep "unknown capability .unknown=silly." output
'
test_done