2008-03-03 03:35:33 +01:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='test automatic tag following'
|
|
|
|
|
2020-11-19 00:44:31 +01:00
|
|
|
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-19 00:44:19 +01:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
2008-03-03 03:35:33 +01:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
# End state of the repository:
|
|
|
|
#
|
|
|
|
# T - tag1 S - tag2
|
|
|
|
# / /
|
|
|
|
# L - A ------ O ------ B
|
|
|
|
# \ \ \
|
|
|
|
# \ C - origin/cat \
|
2020-11-19 00:44:31 +01:00
|
|
|
# origin/main main
|
2008-03-03 03:35:33 +01:00
|
|
|
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
test_expect_success setup '
|
2008-03-03 03:35:33 +01:00
|
|
|
test_tick &&
|
|
|
|
echo ichi >file &&
|
|
|
|
git add file &&
|
|
|
|
git commit -m L &&
|
|
|
|
L=$(git rev-parse --verify HEAD) &&
|
|
|
|
|
|
|
|
(
|
|
|
|
mkdir cloned &&
|
|
|
|
cd cloned &&
|
|
|
|
git init-db &&
|
|
|
|
git remote add -f origin ..
|
|
|
|
) &&
|
|
|
|
|
|
|
|
test_tick &&
|
|
|
|
echo A >file &&
|
|
|
|
git add file &&
|
|
|
|
git commit -m A &&
|
|
|
|
A=$(git rev-parse --verify HEAD)
|
|
|
|
'
|
|
|
|
|
|
|
|
U=UPLOAD_LOG
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
UPATH="$(pwd)/$U"
|
2008-03-03 03:35:33 +01:00
|
|
|
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
test_expect_success 'setup expect' '
|
2008-03-03 03:35:33 +01:00
|
|
|
cat - <<EOF >expect
|
|
|
|
want $A
|
|
|
|
EOF
|
2010-08-11 21:04:07 +02:00
|
|
|
'
|
|
|
|
|
2013-02-20 20:55:28 +01:00
|
|
|
get_needs () {
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
test -s "$1" &&
|
2013-02-20 20:55:28 +01:00
|
|
|
perl -alne '
|
|
|
|
next unless $F[1] eq "upload-pack<";
|
2019-02-25 22:54:09 +01:00
|
|
|
next unless $F[2] eq "want";
|
2013-02-20 20:55:28 +01:00
|
|
|
print $F[2], " ", $F[3];
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
' "$1"
|
2013-02-20 20:55:28 +01:00
|
|
|
}
|
|
|
|
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
test_expect_success 'fetch A (new commit : 1 connection)' '
|
2010-10-31 08:30:58 +01:00
|
|
|
rm -f $U &&
|
2008-03-03 03:35:33 +01:00
|
|
|
(
|
|
|
|
cd cloned &&
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
GIT_TRACE_PACKET=$UPATH git fetch &&
|
2020-11-19 00:44:31 +01:00
|
|
|
test $A = $(git rev-parse --verify origin/main)
|
2008-03-03 03:35:33 +01:00
|
|
|
) &&
|
2013-02-20 20:55:28 +01:00
|
|
|
get_needs $U >actual &&
|
2008-05-24 07:28:56 +02:00
|
|
|
test_cmp expect actual
|
2008-03-03 03:35:33 +01:00
|
|
|
'
|
|
|
|
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
test_expect_success "create tag T on A, create C on branch cat" '
|
2008-03-03 03:35:33 +01:00
|
|
|
git tag -a -m tag1 tag1 $A &&
|
|
|
|
T=$(git rev-parse --verify tag1) &&
|
|
|
|
|
|
|
|
git checkout -b cat &&
|
|
|
|
echo C >file &&
|
|
|
|
git add file &&
|
|
|
|
git commit -m C &&
|
|
|
|
C=$(git rev-parse --verify HEAD) &&
|
2020-11-19 00:44:31 +01:00
|
|
|
git checkout main
|
2008-03-03 03:35:33 +01:00
|
|
|
'
|
|
|
|
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
test_expect_success 'setup expect' '
|
2008-03-03 03:35:33 +01:00
|
|
|
cat - <<EOF >expect
|
|
|
|
want $C
|
|
|
|
want $T
|
|
|
|
EOF
|
2010-08-11 21:04:07 +02:00
|
|
|
'
|
|
|
|
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
test_expect_success 'fetch C, T (new branch, tag : 1 connection)' '
|
2010-10-31 08:30:58 +01:00
|
|
|
rm -f $U &&
|
2008-03-03 03:35:33 +01:00
|
|
|
(
|
|
|
|
cd cloned &&
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
GIT_TRACE_PACKET=$UPATH git fetch &&
|
2008-03-03 03:35:33 +01:00
|
|
|
test $C = $(git rev-parse --verify origin/cat) &&
|
|
|
|
test $T = $(git rev-parse --verify tag1) &&
|
|
|
|
test $A = $(git rev-parse --verify tag1^0)
|
|
|
|
) &&
|
2013-02-20 20:55:28 +01:00
|
|
|
get_needs $U >actual &&
|
2008-05-24 07:28:56 +02:00
|
|
|
test_cmp expect actual
|
2008-03-03 03:35:33 +01:00
|
|
|
'
|
|
|
|
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
test_expect_success "create commits O, B, tag S on B" '
|
2008-03-03 03:35:33 +01:00
|
|
|
test_tick &&
|
|
|
|
echo O >file &&
|
|
|
|
git add file &&
|
|
|
|
git commit -m O &&
|
|
|
|
|
|
|
|
test_tick &&
|
|
|
|
echo B >file &&
|
|
|
|
git add file &&
|
|
|
|
git commit -m B &&
|
|
|
|
B=$(git rev-parse --verify HEAD) &&
|
|
|
|
|
|
|
|
git tag -a -m tag2 tag2 $B &&
|
|
|
|
S=$(git rev-parse --verify tag2)
|
|
|
|
'
|
|
|
|
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
test_expect_success 'setup expect' '
|
2008-03-03 03:35:33 +01:00
|
|
|
cat - <<EOF >expect
|
|
|
|
want $B
|
|
|
|
want $S
|
|
|
|
EOF
|
2010-08-11 21:04:07 +02:00
|
|
|
'
|
|
|
|
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
test_expect_success 'fetch B, S (commit and tag : 1 connection)' '
|
2010-10-31 08:30:58 +01:00
|
|
|
rm -f $U &&
|
2008-03-03 03:35:33 +01:00
|
|
|
(
|
|
|
|
cd cloned &&
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
GIT_TRACE_PACKET=$UPATH git fetch &&
|
2020-11-19 00:44:31 +01:00
|
|
|
test $B = $(git rev-parse --verify origin/main) &&
|
2008-03-03 03:35:33 +01:00
|
|
|
test $B = $(git rev-parse --verify tag2^0) &&
|
|
|
|
test $S = $(git rev-parse --verify tag2)
|
|
|
|
) &&
|
2013-02-20 20:55:28 +01:00
|
|
|
get_needs $U >actual &&
|
2008-05-24 07:28:56 +02:00
|
|
|
test_cmp expect actual
|
2008-03-03 03:35:33 +01:00
|
|
|
'
|
|
|
|
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
test_expect_success 'setup expect' '
|
2008-03-04 04:27:40 +01:00
|
|
|
cat - <<EOF >expect
|
|
|
|
want $B
|
|
|
|
want $S
|
|
|
|
EOF
|
2010-08-11 21:04:07 +02:00
|
|
|
'
|
|
|
|
|
2020-11-19 00:44:31 +01:00
|
|
|
test_expect_success 'new clone fetch main and tags' '
|
2015-03-20 11:10:21 +01:00
|
|
|
test_might_fail git branch -D cat &&
|
|
|
|
rm -f $U &&
|
2008-03-04 04:27:40 +01:00
|
|
|
(
|
|
|
|
mkdir clone2 &&
|
|
|
|
cd clone2 &&
|
|
|
|
git init &&
|
|
|
|
git remote add origin .. &&
|
do not use GIT_TRACE_PACKET=3 in tests
Some test scripts use the GIT_TRACE mechanism to dump
debugging information to descriptor 3 (and point it to a
file using the shell). On Windows, however, bash is unable
to set up descriptor 3. We do not write our trace to the
file, and worse, we may interfere with other operations
happening on descriptor 3, causing tests to fail or even
behave inconsistently.
Prior to commit 97a83fa (upload-pack: remove packet debugging
harness), these tests used GIT_DEBUG_SEND_PACK, which only
supported output to a descriptor. The tests in t5503 were
always broken on Windows, and were marked to be skipped via
the NOT_MINGW prerequisite. In t5700, the tests used to pass
prior to 97a83fa, but only because they were not careful
enough; because we only grepped the trace file, an empty
file looked successful to us. But post-97a83fa, the writing
to descriptor 3 causes "git fetch" to hang (presumably
because we are throwing random bytes into the middle of the
protocol).
Now that we are using the GIT_TRACE mechanism, we can
improve both scripts by asking git to write directly to a
file rather than a descriptor. That fixes the hang in t5700,
and should allow t5503 to successfully run on Windows.
In both cases we now also use "test -s" to double-check that
our trace file actually contains output, which should reduce
the possibility of an erroneously passing test.
Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-20 18:43:47 +01:00
|
|
|
GIT_TRACE_PACKET=$UPATH git fetch &&
|
2020-11-19 00:44:31 +01:00
|
|
|
test $B = $(git rev-parse --verify origin/main) &&
|
2008-03-04 04:27:40 +01:00
|
|
|
test $S = $(git rev-parse --verify tag2) &&
|
|
|
|
test $B = $(git rev-parse --verify tag2^0) &&
|
|
|
|
test $T = $(git rev-parse --verify tag1) &&
|
|
|
|
test $A = $(git rev-parse --verify tag1^0)
|
|
|
|
) &&
|
2013-02-20 20:55:28 +01:00
|
|
|
get_needs $U >actual &&
|
2008-05-24 07:28:56 +02:00
|
|
|
test_cmp expect actual
|
2008-03-04 04:27:40 +01:00
|
|
|
'
|
|
|
|
|
2022-02-17 14:04:16 +01:00
|
|
|
test_expect_success 'atomic fetch with failing backfill' '
|
|
|
|
git init clone3 &&
|
|
|
|
|
|
|
|
# We want to test whether a failure when backfilling tags correctly
|
|
|
|
# aborts the complete transaction when `--atomic` is passed: we should
|
|
|
|
# neither create the branch nor should we create the tag when either
|
|
|
|
# one of both fails to update correctly.
|
|
|
|
#
|
|
|
|
# To trigger failure we simply abort when backfilling a tag.
|
|
|
|
write_script clone3/.git/hooks/reference-transaction <<-\EOF &&
|
|
|
|
while read oldrev newrev reference
|
|
|
|
do
|
|
|
|
if test "$reference" = refs/tags/tag1
|
|
|
|
then
|
|
|
|
exit 1
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
EOF
|
|
|
|
|
|
|
|
test_must_fail git -C clone3 fetch --atomic .. $B:refs/heads/something &&
|
2022-02-17 14:04:36 +01:00
|
|
|
test_must_fail git -C clone3 rev-parse --verify refs/heads/something &&
|
|
|
|
test_must_fail git -C clone3 rev-parse --verify refs/tags/tag2
|
2022-02-17 14:04:16 +01:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'atomic fetch with backfill should use single transaction' '
|
|
|
|
git init clone4 &&
|
|
|
|
|
|
|
|
# Fetching with the `--atomic` flag should update all references in a
|
|
|
|
# single transaction, including backfilled tags. We thus expect to see
|
|
|
|
# a single reference transaction for the created branch and tags.
|
|
|
|
cat >expected <<-EOF &&
|
|
|
|
prepared
|
|
|
|
$ZERO_OID $B refs/heads/something
|
|
|
|
$ZERO_OID $S refs/tags/tag2
|
2022-02-17 14:04:36 +01:00
|
|
|
$ZERO_OID $T refs/tags/tag1
|
2022-02-17 14:04:16 +01:00
|
|
|
committed
|
|
|
|
$ZERO_OID $B refs/heads/something
|
|
|
|
$ZERO_OID $S refs/tags/tag2
|
|
|
|
$ZERO_OID $T refs/tags/tag1
|
|
|
|
EOF
|
|
|
|
|
|
|
|
write_script clone4/.git/hooks/reference-transaction <<-\EOF &&
|
|
|
|
( echo "$*" && cat ) >>actual
|
|
|
|
EOF
|
|
|
|
|
|
|
|
git -C clone4 fetch --atomic .. $B:refs/heads/something &&
|
|
|
|
test_cmp expected clone4/actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'backfill failure causes command to fail' '
|
|
|
|
git init clone5 &&
|
|
|
|
|
2022-03-03 08:20:05 +01:00
|
|
|
# Create a tag that is nested below the tag we are about to fetch via
|
|
|
|
# the backfill mechanism. This causes a D/F conflict when backfilling
|
|
|
|
# and should thus cause the command to fail.
|
|
|
|
empty_blob=$(git -C clone5 hash-object -w --stdin </dev/null) &&
|
|
|
|
git -C clone5 update-ref refs/tags/tag1/nested $empty_blob &&
|
2022-02-17 14:04:16 +01:00
|
|
|
|
2022-02-17 14:04:28 +01:00
|
|
|
test_must_fail git -C clone5 fetch .. $B:refs/heads/something &&
|
2022-02-17 14:04:16 +01:00
|
|
|
test $B = $(git -C clone5 rev-parse --verify refs/heads/something) &&
|
|
|
|
test $S = $(git -C clone5 rev-parse --verify tag2) &&
|
|
|
|
test_must_fail git -C clone5 rev-parse --verify tag1
|
|
|
|
'
|
|
|
|
|
2008-03-03 03:35:33 +01:00
|
|
|
test_done
|