git/t/t5607-clone-bundle.sh

87 lines
2.4 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='some bundle related tests'
. ./test-lib.sh
test_expect_success 'setup' '
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 master &&
test_must_fail nongit 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 &&
git ls-remote bundle > output &&
grep tag output &&
git bundle create bundle --all --since=7.Apr.2005.15:16:00.-0700 &&
git ls-remote bundle > output &&
! grep tag output
'
test_expect_success 'die if bundle file cannot be created' '
mkdir adir &&
test_must_fail git bundle create adir --all
'
test_expect_failure 'bundle --stdin' '
echo master | git bundle create stdin-bundle.bdl --stdin &&
git ls-remote stdin-bundle.bdl >output &&
grep master output
'
test_expect_failure 'bundle --stdin <rev-list options>' '
echo master | git bundle create hybrid-bundle.bdl --stdin tag &&
git ls-remote hybrid-bundle.bdl >output &&
grep master output
'
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 &&
git bundle list-heads long-subject-bundle.bdl >heads &&
test -s heads &&
git fetch long-subject-bundle.bdl &&
sed -n "/^-/{p;q;}" long-subject-bundle.bdl >boundary &&
grep "^-[0-9a-f]\\{40\\} " boundary
'
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 master..master &&
test_path_is_missing fail.bundle.lock
'
test_done