summaryrefslogtreecommitdiff
path: root/t/t5150-request-pull.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-02-10tests: remove most uses of test_i18ncmpLibravatar Ævar Arnfjörð Bjarmason1-2/+2
As a follow-up to d162b25f956 (tests: remove support for GIT_TEST_GETTEXT_POISON, 2021-01-20) remove most uses of test_i18ncmp via a simple s/test_i18ncmp/test_cmp/g search-replacement. I'm leaving t6300-for-each-ref.sh out due to a conflict with in-flight changes between "master" and "seen", as well as the prerequisite itself due to other changes between "master" and "next/seen" which add new test_i18ncmp uses. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19t5[0-4]*: adjust the references to the default branch name "main"Libravatar Johannes Schindelin1-18/+18
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>
2020-02-24t: drop debug `cat` callsLibravatar Martin Ågren1-2/+0
We `cat` files, but don't inspect or grab the contents in any way. Unlike in an earlier commit, there is no reason to suspect that these files could be missing, so `cat`-ing them is just wasted effort. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-27t5150: skip request-pull test if Perl is disabledLibravatar Ruud van Asseldonk1-0/+6
The git-request-pull.sh script invokes Perl, so it requires Perl to be available, but the associated test t5150 does not skip itself when Perl has been disabled, which then makes subtest 4 through 10 fail. Subtest 3 still passes, but for the wrong reasons (it expects git-request-pull to fail, and it does fail when Perl is not available). The initial two subtests that do pass are only doing setup. To prevent t5150 from failing the build when NO_PERL=1, add a check that sets skip_all when "! test_have_prereq PERL", just like how for example t3701-add-interactive skips itself when Perl has been disabled. Signed-off-by: Ruud van Asseldonk <dev@veniogames.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28request-pull: warn if the remote object is not the same as the local oneLibravatar Paolo Bonzini1-0/+35
In some cases, git request-pull might be invoked with remote and local objects that differ even though they point to the same commit. For example, the remote object might be a lightweight tag vs. an annotated tag on the local side; or the user might have reworded the tag locally and forgotten to push it. When this happens git-request-pull will not warn, because it only checks that "git ls-remote" returns an SHA1 that matches the local commit (known as $headrev in the script). This patch makes git-request-pull retrieve the tag object SHA1 while processing the "git ls-remote" output, so that it can be matched against the local object. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-28request-pull: quote regex metacharacters in local refLibravatar Paolo Bonzini1-0/+18
The local part of the third argument of git-request-pull is used in a regular expression without quoting it. Use qr{} and \Q\E to ensure that e.g. a period in a tag name does not match any character on the remote side. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-14t: switch $_x40 to $OID_REGEXLibravatar brian m. carlson1-1/+1
Switch all uses of $_x40 to $OID_REGEX so that they work correctly with larger hashes. This commit was created by using the following sed command to modify all files in the t directory except t/test-lib.sh: sed -i 's/\$_x40/$OID_REGEX/g' Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-03request-pull: capitalise "Git" to make it a proper nounLibravatar Ann T Ropea1-2/+2
Of the many ways to spell the three-letter word, the variant "Git" should be used when referring to a repository in a description; or, in general, when it is used as a proper noun. We thus change the pull-request template message so that it reads "...in the Git repository at:" Besides, this brings us in line with the documentation, see Documentation/howto/using-signed-tag-in-pull-request.txt Signed-off-by: Ann T Ropea <bedhanger@gmx.de> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-02fix brown paper bag breakage in t5150-request-pull.shLibravatar Johannes Sixt1-1/+1
The recent addition to the test case 'pull request format' interrupted the single-quoted text, effectively adding a third argument to the test_expect_success command. Since we do not have a prerequisite named "pull request format", the test is skipped, no matter what. Additionally, the file name argument to the grep command is missing. Fix both issues. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-16request-pull: resurrect for-linus -> tags/for-linus DWIMLibravatar Junio C Hamano1-1/+7
Older versions of Git before v1.7.10 did not DWIM $ git pull $URL for-linus to the tag "tags/for-linus" and the users were required to say $ git pull $URL tags/for-linus instead. Because newer versions of Git works either way, request-pull used to show tags/for-linus when asked $ git request-pull origin/master $URL for-linus The recent updates broke this and in the output we see "for-linus" without the "tags/" prefix. As v1.7.10 is more than 2 years old, this should matter very little in practice, but resurrecting it is very simple. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-25request-pull: resurrect "pretty refname" featureLibravatar Junio C Hamano1-1/+7
When asking to fetch/pull a branch whose name is B or a tag whose name is T, we used to show the command to run as: git pull $URL B git pull $URL tags/T even when B and T were spelled in a more qualified way in order to disambiguate, e.g. heads/B or refs/tags/T, but the recent update lost this feature. Resurrect it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-25request-pull: test updatesLibravatar Junio C Hamano1-8/+8
This illustrates behaviour changes that result from the recent change by Linus. Most show good changes, but there may be some usability regressions: - The command continues to fail when the user forgot to push out before running the command, but the wording of the message has been slightly changed. - The command no longer guesses when asked to request the commit at the HEAD be pulled after pushing it to a branch 'for-upstream', even when that branch points at the correct commit. The user must ask the command with the new "master:for-upstream" syntax. The new behaviour needs to be documented in any case, but we need to agree what the new behaviour should be before doing so first. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-17tests: allow sha1's as part of the pathLibravatar Dennis Kaarsemaker1-1/+1
When running 'make test' from a path such as .../daily-build/master@bdff0e3a374617dce784f801b97500d9ba2e4705, the logic in fuzz.sed as generated by t5105-request-pull.sh was backwards, replacing object names before replacing urls, making the test fail. Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-13test: use test_i18ncmp when checking --stat outputLibravatar Jonathan Nieder1-1/+1
Ever since v1.7.9.2~13 (2012-02-01), git's diffstat-style summary line produced by "git apply --stat", "git diff --stat", and "git commit" varies by locale, producing test failures when GETTEXT_POISON is set. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-12Merge branch 'nd/diffstat-gramnum'Libravatar Junio C Hamano1-1/+1
* nd/diffstat-gramnum: Use correct grammar in diffstat summary line
2012-02-03Use correct grammar in diffstat summary lineLibravatar Nguyễn Thái Ngọc Duy1-1/+1
"git diff --stat" and "git apply --stat" now learn to print the line "%d files changed, %d insertions(+), %d deletions(-)" in singular form whenever applicable. "0 insertions" and "0 deletions" are also omitted unless they are both zero. This matches how versions of "diffstat" that are not prehistoric produced their output, and also makes this line translatable. [jc: with help from Thomas Dickey in archaeology of "diffstat"] [jc: squashed Jonathan's updates to illustrations in tutorials and a test] Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-31request-pull: explicitly ask tags/$name to be pulledLibravatar Junio C Hamano1-5/+1
When asking for a tag to be pulled, disambiguate by leaving tags/ prefix in front of the name of the tag. E.g. ... in the git repository at: git://example.com/git/git.git/ tags/v1.2.3 for you to fetch changes up to 123456... This way, older versions of "git pull" can be used to respond to such a request more easily, as "git pull $URL v1.2.3" did not DWIM to fetch v1.2.3 tag in older versions. Also this makes it clearer for humans that the pull request is made for a tag and he should anticipate a signed one. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-19request-pull: do not emit "tag" before the tagnameLibravatar Junio C Hamano1-1/+1
The whole point of the recent update to allow "git pull $url $tagname" is so that the integrator does not have to store the (signed) tag that is used to convey authenticity to be recorded in the resulting merge in the local repository's tag namespace. Asking for a merge be made with "git pull $url tag $tagname" defeats it. Note that the request can become ambiguous if the requestor has a branch with the same name as the tag, but that is not a new problem limited to pulling. I wouldn't mind if somebody wants to add disambiguation to the find_matching_ref logic in the script as a separate patch, though. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-16request-pull: update the "pull" command generation logicLibravatar Junio C Hamano1-0/+3
The old code that insisted on asking for the tip of a branch to be pulled were not updated when we started allowing for a tag to be pulled. When a tag points at an older part of the history and there is no branch that points at the tagged commit, the script failed to say which ref is to be pulled. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-09request-pull: use the annotated tag contentsLibravatar Junio C Hamano1-0/+4
The integrator tool will start allowing to pull a signed or an annotated tag, i.e. $ git pull $there tags/for-linus and the description in the tag is used to convey a meaningful message from the lieutenant to the integrator to justify the history being pulled. Include the message in the pull request e-mail, as the same information is useful in this context, too. It would encourage the lieutenants to write meaningful messages in their signed tags. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05request-pull: state what commit to expectLibravatar Junio C Hamano1-0/+6
The message gives a detailed explanation of the commit the requester based the changes on, but lacks information that is necessary for the person who performs a fetch & merge in order to verify that the correct branch was fetched when responding to the pull request. Add a few more lines to describe the commit at the tip expected to be fetched to the same level of detail as the base commit. Also update the warning message slightly when the script notices that the commit may not have been pushed. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-02t/t5150: remove space from sed scriptLibravatar Brandon Casey1-2/+2
Solaris's xpg4/sed and IRIX's sed fail to parse these negated matching expressions when the '!' is separated from the command that follows. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-10tests: chmod +x t5150Libravatar Jeff King1-0/+0
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-07adapt request-pull tests for new pull request formatLibravatar Jonathan Nieder1-5/+5
10eb0007 (request-pull: avoid mentioning that the start point is a single commit, 2010-01-29), changed the pull request format, so the test needs some changes to still pass: - tolerate a missing blank line between “in the git repository at:” and the name of repository and branch - recognize subject and date in the new request format - update the expected request template to match the new format Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-07t5150: protect backslash with backslash in shellLibravatar Junio C Hamano1-2/+2
At least /bin/sh on FreeBSD 8 interprets backslash followed by newline in an unquoted here text as "empty". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-01request-pull: protect against OPTIONS_KEEPDASHDASH from environmentLibravatar Jonathan Nieder1-0/+14
Like most git commands, request-pull supports a -- delimiter to allow callers to pass arguments that would otherwise be treated as an option afterwards. The internal OPTIONS_KEEPDASHDASH variable is passed empty to git-sh-setup to indicate that request-pull itself does not care about the position of the -- delimiter. But if the user has that variable in her environment, request-pull will see the “--” and fail. Empty it explicitly to guard against this. While at it, make the corresponding fix to git-resurrect, too (all other scripts in git.git already protect themselves). Acked-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-01tests for request-pullLibravatar Jonathan Nieder1-0/+214
Test that request-pull handles failure to push cleanly, writes pull requests that produce the correct effect when followed, and uses a predictable format. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>