summaryrefslogtreecommitdiff
path: root/t/t7601-merge-pull-config.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-07-22pull: fix handling of multiple headsLibravatar Elijah Newren1-1/+1
With multiple heads, we should not allow rebasing or fast-forwarding. Make sure any fast-forward request calls out specifically the fact that multiple branches are in play. Also, since we cannot fast-forward to multiple branches, fix our computation of can_ff. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-22pull: abort by default when fast-forwarding is not possibleLibravatar Elijah Newren1-24/+24
We have for some time shown a long warning when the user does not specify how to reconcile divergent branches with git pull. Make it an error now. Initial-patch-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-22pull: make --rebase and --no-rebase override pull.ff=onlyLibravatar Elijah Newren1-2/+2
Fix the last few precedence tests failing in t7601 by now implementing the logic to have --[no-]rebase override a pull.ff=only config setting. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20pull: abort if --ff-only is given and fast-forwarding is impossibleLibravatar Alex Henrie1-5/+5
The warning about pulling without specifying how to reconcile divergent branches says that after setting pull.rebase to true, --ff-only can still be passed on the command line to require a fast-forward. Make that actually work. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> [en: updated tests; note 3 fixes and 1 new failure] Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20t7601: add tests of interactions with multiple merge heads and configLibravatar Elijah Newren1-0/+22
There were already code checking that --rebase was incompatible with a merge of multiple heads. However, we were sometimes throwing warnings about lack of specification of rebase vs. merge when given multiple heads. Since rebasing is disallowed with multiple merge heads, that seems like a poor warning to print; we should instead just assume merging is wanted. Add a few tests checking multiple merge head behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-20t7601: test interaction of merge/rebase/fast-forward flags and optionsLibravatar Elijah Newren1-0/+182
The interaction of rebase and merge flags and options was not well tested. Add several tests to check for correct behavior from the following rules: * --ff-only vs. --[no-]rebase (and the related pull.ff=only vs. pull.rebase) * --rebase[=!false] vs. --no-ff and --ff (and the related pull.rebase=!false overrides pull.ff=!only) * command line flags take precedence over config, except: * --no-rebase heeds pull.ff=!only * pull.rebase=!false vs --no-ff and --ff For more details behind these rules and a larger table of individual cases, refer to https://lore.kernel.org/git/xmqqwnpqot4m.fsf@gitster.g/ and the links found therein. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-15pull: display default warning only when non-ffLibravatar Felipe Contreras1-5/+61
There's no need to display the annoying warning on every pull... only the ones that are not fast-forward. The current warning tests still pass, but not because of the arguments or the configuration, but because they are all fast-forward. We need to test non-fast-forward situations now. Suggestions-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19pull: colorize the hint about setting `pull.rebase`Libravatar Johannes Schindelin1-2/+5
In d18c950a69f (pull: warn if the user didn't say whether to rebase or to merge, 2020-03-09), a new hint was introduced to encourage users to make a conscious decision about whether they want their pull to merge or to rebase by configuring the `pull.rebase` setting. This warning was clearly intended to advise users, but as pointed out in https://lore.kernel.org/git/87ima2rdsm.fsf%40evledraar.gmail.com, it uses `warning()` instead of `advise()`. One consequence is that the advice is not colorized in the same manner as other, similar messages. So let's use `advise()` instead. Pointed-out-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-24pull: don't warn if pull.ff has been setLibravatar Alex Henrie1-1/+20
A user who understands enough to set pull.ff does not need additional instructions. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-10pull: warn if the user didn't say whether to rebase or to mergeLibravatar Alex Henrie1-0/+38
Often novice Git users forget to say "pull --rebase" and end up with an unnecessary merge from upstream. What they usually want is either "pull --rebase" in the simpler cases, or "pull --ff-only" to update the copy of main integration branches, and rebase their work separately. The pull.rebase configuration variable exists to help them in the simpler cases, but there is no mechanism to make these users aware of it. Issue a warning message when no --[no-]rebase option from the command line and no pull.rebase configuration variable is given. This will inconvenience those who never want to "pull --rebase", who haven't had to do anything special, but the cost of the inconvenience is paid only once per user, which should be a reasonable cost to help a number of new users. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-18pull: make pull.ff=true override merge.ffLibravatar Paul Tan1-0/+8
Since b814da8 (pull: add pull.ff configuration, 2014-01-15), running git-pull with the configuration pull.ff=false or pull.ff=only is equivalent to passing --no-ff and --ff-only to git-merge. However, if pull.ff=true, no switch is passed to git-merge. This leads to the confusing behavior where pull.ff=false or pull.ff=only is able to override merge.ff, while pull.ff=true is unable to. Fix this by adding the --ff switch if pull.ff=true, and add a test to catch future regressions. Furthermore, clarify in the documentation that pull.ff overrides merge.ff. Signed-off-by: Paul Tan <pyokagan@gmail.com> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-15pull: add pull.ff configurationLibravatar David Aguilar1-0/+21
Add a `pull.ff` configuration option that is analogous to the `merge.ff` option. This allows us to control the fast-forward behavior for pull-initiated merges only. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-29many small typofixesLibravatar Ondřej Bílka1-1/+1
Signed-off-by: Ondřej Bílka <neleai@seznam.cz> Reviewed-by: Marc Branchaud <marcnarc@xiplink.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-12Correct common spelling mistakes in comments and testsLibravatar Stefano Lattarini1-1/+1
Most of these were found using Lucas De Marchi's codespell tool. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-06t7601 (merge-pull-config): add missing &&Libravatar Elijah Newren1-6/+6
Also prefix several relevant git merge commands with 'test_must_fail' to keep the tests passing. Acked-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03tests: use "git xyzzy" form (t7200 - t9001)Libravatar Nanako Shiraishi1-1/+1
Converts tests between t7201-t9001. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-23t7601: extend the 'merge picks up the best result' testLibravatar Miklos Vajna1-0/+15
The test only checked if the best result picking code works if there are multiple strategies set in the config. Add a similar one that tests if the same true if the -s option of git merge was used multiple times. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-21builtin-merge: give a proper error message for invalid strategies in configLibravatar Miklos Vajna1-0/+12
'git merge -s foobar' diagnosed invalid "foobar" strategy and errored out with a message, but foobar in pull.twohead or pull.octopus was just silently ignored. This makes invalid strategy both on the command line and in the configuration file to trigger the same error. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-06Fix t7601-merge-pull-config.sh on AIXLibravatar Miklos Vajna1-7/+7
The test failed on AIX (and likely other OS, such as apparently OSX) where wc -l outputs whitespace. Also, avoid unnecessary eval in conflict_count(). Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-30Add new test to ensure git-merge handles pull.twohead and pull.octopusLibravatar Miklos Vajna1-0/+129
Test if the given strategies are used and test the case when multiple strategies are configured using a space separated list. Also test if the best strategy is picked if none is specified. This is done by adding a simple test case where recursive detects a rename, but resolve does not, and verify that finally merge will pick up the previous. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-14 13:24:25 +0000