summaryrefslogtreecommitdiff
path: root/t/t3508-cherry-pick-many-commits.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-19t3[5-9]*: adjust the references to the default branch name "main"Libravatar Johannes Schindelin1-20/+20
This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t3[5-9]*.sh) 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>
2019-11-21t: teach test_cmp_rev to accept ! for not-equalsLibravatar Denton Liu1-1/+1
In the case where we are using test_cmp_rev() to report not-equals, we write `! test_cmp_rev`. However, since test_cmp_rev() contains r1=$(git rev-parse --verify "$1") && r2=$(git rev-parse --verify "$2") && `! test_cmp_rev` will succeed if any of the rev-parses fail. This behavior is not desired. We want the rev-parses to _always_ be successful. Rewrite test_cmp_rev() to optionally accept "!" as the first argument to do a not-equals comparison. Rewrite `! test_cmp_rev` to `test_cmp_rev !` in all tests to take advantage of this new functionality. Also, rewrite the rev-parse logic to end with a `|| return 1` instead of &&-chaining into the rev-comparison logic. This makes it obvious to future readers that we explicitly intend on returning early if either of the rev-parses fail. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-02commit: print "Date" line when the user has set dateLibravatar Jeff King1-0/+6
When we make a commit and the author is not the same as the committer (e.g., because you used "-c $commit" or "--author=$somebody"), we print the author's name and email in both the commit-message template and as part of the commit summary. This is a safety check to give the user a chance to confirm that we are doing what they expect. This patch brings the same safety for the "date" field, which may be set by "-c" or by using "--date". Note that we explicitly do not set it for $GIT_AUTHOR_DATE, as it is probably not of interest when "git commit" is being fed its parameters by a script. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-11cherry-pick: make sure all input objects are commitsLibravatar Miklos Vajna1-0/+6
When a single argument was a non-commit, the error message used to be: fatal: BUG: expected exactly one commit from walk For multiple arguments, when none of the arguments was a commit, the error was: fatal: empty commit set passed Finally, when some of the arguments were non-commits, we ignored those arguments. Fix this bug and make sure all arguments are commits, and for the first non-commit, error out with: fatal: <name>: Can't cherry-pick a <type> Signed-off-by: Miklos Vajna <vmiklos@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-22tests: move test_cmp_rev to test-lib-functionsLibravatar Martin von Zweigbergk1-6/+2
A function for checking that two given parameters refer to the same revision was defined in several places, so move the definition to test-lib-functions.sh instead. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30cherry-pick/revert: respect order of revisions to pickLibravatar Martin von Zweigbergk1-1/+1
When giving multiple individual revisions to cherry-pick or revert, as in 'git cherry-pick A B' or 'git revert B A', one would expect them to be picked/reverted in the order given on the command line. They are instead ordered by their commit timestamp -- in chronological order for "cherry-pick" and in reverse chronological order for "revert". This matches the order in which one would usually give them on the command line, making this bug somewhat hard to notice. Still, it has been reported at least once before [1]. It seems like the chronological sorting happened by accident because the revision walker has traditionally always sorted commits in reverse chronological order when rev_info.no_walk was enabled. In the case of 'git revert B A' where B is newer than A, this sorting is a no-op. For 'git cherry-pick A B', the sorting would reverse the arguments, but because the sequencer also flips the rev_info.reverse flag when picking (as opposed to reverting), the end result is a chronological order. The rev_info.reverse flag was probably flipped so that the revision walker emits B before C in 'git cherry-pick A..C'; that it happened to effectively undo the unexpected sorting done when not walking, was probably a coincidence that allowed this bug to happen at all. Fix the bug by telling the revision walker not to sort the commits when not walking. The only case we want to reverse the order is now when cherry-picking and walking revisions (rev_info.no_walk = 0). [1] http://thread.gmane.org/gmane.comp.version-control.git/164794 Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-30demonstrate broken 'git cherry-pick three one two'Libravatar Martin von Zweigbergk1-0/+15
Cherry-picking commits out of order (w.r.t. commit time stamp) doesn't currently work. Add a test case to demonstrate it. Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-13test: test cherry-pick functionality and output separatelyLibravatar Jonathan Nieder1-8/+22
Since v1.7.3-rc0~26^2~9 (revert: report success when using option --strategy, 2010-07-14), the cherry-pick-many-commits test checks the format of output written to the terminal during a cherry-pick sequence in addition to the functionality. There is no reason those have to be checked in the same test, though, and it has some downsides: - when progress output is broken, the test result does not convey whether the functionality was also broken or not - it is not immediately obvious when reading that these checks are meant to prevent regressions in details of the output format and are not just a roundabout way to check functional details like the number of commits produced - there is a temptation to include the same kind of output checking for every new cherry-pick test, which would make future changes to the output unnecessarily difficult Put the tests from v1.7.3-rc0~26^2~9 in separate assertions, following the principle "test one feature at a time". Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-13test: use test_i18ncmp when checking --stat outputLibravatar Jonathan Nieder1-2/+2
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-03Use correct grammar in diffstat summary lineLibravatar Nguyễn Thái Ngọc Duy1-6/+6
"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>
2010-08-15Eliminate “Finished cherry-pick/revert” messageLibravatar Jonathan Nieder1-12/+30
When cherry-pick was written (v0.99.6~63, 2005-08-27), “git commit” was quiet, and the output from cherry-pick provided useful information about the progress of a rebase. Now next to the output from “git commit”, the cherry-pick notification is so much noise (except for the name of the picked commit). $ git cherry-pick ..topic Finished cherry-pick of 499088b. [detached HEAD 17e1ff2] Move glob module to libdpkg Author: Guillem Jover <guillem@debian.org> 8 files changed, 12 insertions(+), 9 deletions(-) rename {src => lib/dpkg}/glob.c (98%) rename {src => lib/dpkg}/glob.h (93%) Finished cherry-pick of ae947e1. [detached HEAD 058caa3] libdpkg: Add missing symbols to Versions script Author: Guillem Jover <guillem@debian.org> 1 files changed, 2 insertions(+), 0 deletions(-) $ The noise is especially troublesome when sifting through the output of a rebase or multiple cherry-pick that eventually failed. With the commit subject, it is already not hard to figure out where the commit came from. So drop the “Finished” message. Cc: Christian Couder <chriscool@tuxfamily.org> Cc: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-23t3508: add check_head_differs_from() helper function and use itLibravatar Christian Couder1-5/+17
In a test like: test "$(git rev-parse --verify HEAD)" != "$(git rev-parse --verify fourth)" the --verify does not accomplish much, since the exit status of git rev-parse is not propagated to test. So it is more robust to define and use the helper functions check_head_differs_from() and check_head_equals() as done by this patch. Suggested-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-16revert: improve success message by adding abbreviated commit sha1Libravatar Christian Couder1-8/+8
Instead of saying "Finished one cherry-pick." or "Finished one revert.", we now say "Finished cherry-pick of commit <abbreviated sha1>." or "Finished revert of commit <abbreviated sha1>." which is more informative, especially when cherry-picking or reverting many commits. In case of failure the message is now "Automatic cherry-pick of commit <abbreviated sha1> failed." instead of "Automatic cherry-pick failed." Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-16revert: report success when using option --strategyLibravatar Christian Couder1-1/+25
"git cherry-pick foo" has always reported success with "Finished one cherry-pick" but "cherry-pick --strategy" does not print anything. So move the code to write that message from do_recursive_merge() to do_cherry_pick() so other strategies can share it. This patch also refactors the code that prints a message like "Automatic cherry-pick failed. <help message>". This code was duplicated in both do_recursive_merge() and do_pick_commit(). To do that, now do_recursive_merge() returns an int to signal success or failure. And in case of failure we just return 1 from do_pick_commit() instead of doing "exit(1)" from either do_recursive_merge() or do_pick_commit(). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-29Merge commit 'v1.7.2-rc0~6^2' into cc/cherry-pick-stdinLibravatar Junio C Hamano1-1/+1
* commit 'v1.7.2-rc0~6^2': DWIM 'git show -5' to 'git show --do-walk -5' Documentation/SubmittingPatches: Fix typo in GMail section Documentation/config: describe status.submodulesummary This commit fixes one test in t3508 by making "cherry-pick -<num>" walk the history. A test update from Elijah Newren is squashed as an evil merge.
2010-06-25revert: accept arbitrary rev-list optionsLibravatar Christian Couder1-0/+10
This can be useful to do something like: git rev-list --reverse master -- README | git cherry-pick -n --stdin without using xargs. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-14t3508 (cherry-pick): futureproof against unmerged filesLibravatar Jonathan Nieder1-7/+7
Each of the tests in t3508 begins by navigating to a sane state: git checkout master && git reset --hard $commit If a previous test left unmerged files around, they are untouched and the checkout fails, causing later tests to fail, too. This is not a problem in practice because no test except the final one produces unmerged files. But as a futureproofing measure, it is still best to avoid the problem with 'checkout -f'. In particular, this is needed for new tests to be added to the end of the script. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-02revert: add tests to check cherry-picking many commitsLibravatar Christian Couder1-0/+95
Note that there is an expected failure when running: git cherry-pick -3 fourth that's because: git rev-list --no-walk -3 fourth produce only one commit and not 3 as "--no-walk" seems to take over "-3". Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>