summaryrefslogtreecommitdiff
path: root/t/t5404-tracking-branches.sh
AgeCommit message (Collapse)AuthorFilesLines
2020-11-19t5[0-4]*: adjust the references to the default branch name "main"Libravatar Johannes Schindelin1-5/+5
Carefully excluding t5310, which is developed independently of the current patch series at the time of writing, we now use `main` as default branch in t5[0-4]*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t5[0-4]*.sh && git checkout HEAD -- t5310\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19tests: mark tests relying on the current default for `init.defaultBranch`Libravatar Johannes Schindelin1-0/+3
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>
2018-04-09t5404: relax overzealous testLibravatar Johannes Schindelin1-1/+1
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>
2013-01-04t5404: do not assume the "matching" push is the defaultLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13t/: Use "test_must_fail git" instead of "! git"Libravatar Stephan Beyer1-1/+3
This patch changes every occurrence of "! git" -- with the meaning that a git call has to gracefully fail -- into "test_must_fail git". This is useful to - make sure the test does not fail because of a signal, e.g. SIGSEGV, and - advertise the use of "test_must_fail" for new tests. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08make deleting a missing ref more quietLibravatar Jeff King1-0/+7
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>
2007-11-17send-pack: check ref->status before updating tracking refsLibravatar Jeff King1-0/+5
Previously, we manually checked the 'NONE' and 'UPTODATE' conditions. Now that we have ref->status, we can easily say "only update if we pushed successfully". This adds a test for and fixes a regression introduced in ed31df31 where deleted refs did not have their tracking branches removed. This was due to a bogus per-ref error test that is superseded by the more accurate ref->status flag. Signed-off-by: Jeff King <peff@peff.net> Completely-Acked-By: Alex "Sleepy" Riesen <raa.lkml@gmail.com> Acked-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-17send-pack: track errors for each refLibravatar Jeff King1-3/+11
Instead of keeping the 'ret' variable, we instead have a status flag for each ref that tracks what happened to it. We then print the ref status after all of the refs have been examined. This paves the way for three improvements: - updating tracking refs only for non-error refs - incorporating remote rejection into the printed status - printing errors in a different order than we processed (e.g., consolidating non-ff errors near the end with a special message) Signed-off-by: Jeff King <peff@peff.net> Acked-by: Alex Riesen <raa.lkml@gmail.com> Acked-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-12Add a test checking if send-pack updated local tracking branches correctlyLibravatar Alex Riesen1-0/+40
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>