2007-11-12 21:38:23 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='tracking branch update checks for git push'
|
|
|
|
|
2020-11-18 23:44:29 +00: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-18 23:44:19 +00:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
2023-06-17 06:41:54 +00:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2007-11-12 21:38:23 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
test_expect_success 'setup' '
|
|
|
|
echo 1 >file &&
|
|
|
|
git add file &&
|
|
|
|
git commit -m 1 &&
|
|
|
|
git branch b1 &&
|
|
|
|
git branch b2 &&
|
make deleting a missing ref more quiet
If git attempts to delete a ref, but the unlink of the ref
file fails, we print a message to stderr. This is usually a
good thing, but if the error is ENOENT, then it indicates
that the ref has _already_ been deleted. And since that's
our goal, it doesn't make sense to complain to the user.
This harmonizes the error reporting behavior for the
unpacked and packed cases; the packed case already printed
nothing on ENOENT, but the unpacked printed unconditionally.
Additionally, send-pack would, when deleting the tracking
ref corresponding to a remote delete, print "Failed to
delete" on any failure. This can be a misleading
message, since we actually _did_ delete at the remote side,
but we failed to delete locally. Rather than make the
message more precise, let's just eliminate it entirely; the
delete_ref routine already takes care of printing out a much
more specific message about what went wrong.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 04:08:02 +00:00
|
|
|
git branch b3 &&
|
2007-11-12 21:38:23 +00:00
|
|
|
git clone . aa &&
|
|
|
|
git checkout b1 &&
|
|
|
|
echo b1 >>file &&
|
|
|
|
git commit -a -m b1 &&
|
|
|
|
git checkout b2 &&
|
|
|
|
echo b2 >>file &&
|
|
|
|
git commit -a -m b2
|
|
|
|
'
|
|
|
|
|
2007-11-17 12:54:27 +00:00
|
|
|
test_expect_success 'prepare pushable branches' '
|
2007-11-12 21:38:23 +00:00
|
|
|
cd aa &&
|
|
|
|
b1=$(git rev-parse origin/b1) &&
|
|
|
|
b2=$(git rev-parse origin/b2) &&
|
|
|
|
git checkout -b b1 origin/b1 &&
|
|
|
|
echo aa-b1 >>file &&
|
|
|
|
git commit -a -m aa-b1 &&
|
|
|
|
git checkout -b b2 origin/b2 &&
|
|
|
|
echo aa-b2 >>file &&
|
|
|
|
git commit -a -m aa-b2 &&
|
2020-11-18 23:44:29 +00:00
|
|
|
git checkout main &&
|
|
|
|
echo aa-main >>file &&
|
|
|
|
git commit -a -m aa-main
|
2007-11-17 12:54:27 +00:00
|
|
|
'
|
|
|
|
|
2008-07-12 15:47:52 +00:00
|
|
|
test_expect_success 'mixed-success push returns error' '
|
2013-01-05 00:04:22 +00:00
|
|
|
test_must_fail git push origin :
|
2008-07-12 15:47:52 +00:00
|
|
|
'
|
2007-11-17 12:54:27 +00:00
|
|
|
|
|
|
|
test_expect_success 'check tracking branches updated correctly after push' '
|
2020-11-18 23:44:29 +00:00
|
|
|
test "$(git rev-parse origin/main)" = "$(git rev-parse main)"
|
2007-11-17 12:54:27 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'check tracking branches not updated for failed refs' '
|
2007-11-12 21:38:23 +00:00
|
|
|
test "$(git rev-parse origin/b1)" = "$b1" &&
|
|
|
|
test "$(git rev-parse origin/b2)" = "$b2"
|
|
|
|
'
|
|
|
|
|
2007-11-17 12:55:15 +00:00
|
|
|
test_expect_success 'deleted branches have their tracking branches removed' '
|
|
|
|
git push origin :b1 &&
|
|
|
|
test "$(git rev-parse origin/b1)" = "origin/b1"
|
|
|
|
'
|
|
|
|
|
make deleting a missing ref more quiet
If git attempts to delete a ref, but the unlink of the ref
file fails, we print a message to stderr. This is usually a
good thing, but if the error is ENOENT, then it indicates
that the ref has _already_ been deleted. And since that's
our goal, it doesn't make sense to complain to the user.
This harmonizes the error reporting behavior for the
unpacked and packed cases; the packed case already printed
nothing on ENOENT, but the unpacked printed unconditionally.
Additionally, send-pack would, when deleting the tracking
ref corresponding to a remote delete, print "Failed to
delete" on any failure. This can be a misleading
message, since we actually _did_ delete at the remote side,
but we failed to delete locally. Rather than make the
message more precise, let's just eliminate it entirely; the
delete_ref routine already takes care of printing out a much
more specific message about what went wrong.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 04:08:02 +00:00
|
|
|
test_expect_success 'already deleted tracking branches ignored' '
|
|
|
|
git branch -d -r origin/b3 &&
|
|
|
|
git push origin :b3 >output 2>&1 &&
|
t5404: relax overzealous test
In 0b294c0abf0 (make deleting a missing ref more quiet, 2008-07-08), we
added a test to verify that deleting an already-deleted ref does not
show an error.
Our test simply looks for the substring 'error' in the output of the
`git push`, which might look innocuous on the face of it.
Suppose, however, that you are a big fan of whales. Or even better: your
IT administrator has a whale of a time picking cute user names, e.g.
referring to you (due to your like of India Pale Ales) as "one of the
cuter rorquals" (see https://en.wikipedia.org/wiki/Rorqual to learn a
thing or two about rorquals) and hence your home directory becomes
/home/cuterrorqual. If you now run t5404, it fails! Why? Because the
test calls `git push origin :b3` which outputs:
To /home/cuterrorqual/git/t/trash directory.t5404-tracking-branches/.
- [deleted] b3
Note how there is no error displayed in that output? But of course
"error" is a substring of "cuterrorqual". And so that `grep error
output` finds something.
This bug was not, actually, caught having "error" as a substring of the
user name but while working in a worktree called "colorize-push-errors",
whose name was part of that output, too, suggesting that not even
testing for the *word* `error` via `git grep -w error output` would fix
the underlying issue.
This patch chooses instead to look for the prefix "error:" at the
beginning of the line, so that there can be no ambiguity that any catch
was indeed a message generated by Git's `error_builtin()` function.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-06 19:31:22 +00:00
|
|
|
! grep "^error: " output
|
make deleting a missing ref more quiet
If git attempts to delete a ref, but the unlink of the ref
file fails, we print a message to stderr. This is usually a
good thing, but if the error is ENOENT, then it indicates
that the ref has _already_ been deleted. And since that's
our goal, it doesn't make sense to complain to the user.
This harmonizes the error reporting behavior for the
unpacked and packed cases; the packed case already printed
nothing on ENOENT, but the unpacked printed unconditionally.
Additionally, send-pack would, when deleting the tracking
ref corresponding to a remote delete, print "Failed to
delete" on any failure. This can be a misleading
message, since we actually _did_ delete at the remote side,
but we failed to delete locally. Rather than make the
message more precise, let's just eliminate it entirely; the
delete_ref routine already takes care of printing out a much
more specific message about what went wrong.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 04:08:02 +00:00
|
|
|
'
|
|
|
|
|
2007-11-12 21:38:23 +00:00
|
|
|
test_done
|