summaryrefslogtreecommitdiff
path: root/t/t5520-pull.sh
AgeCommit message (Collapse)AuthorFilesLines
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-05-20t5520: avoid alternation in grep's BRE (not POSIX)Libravatar Carlo Marcelo Arenas Belón1-1/+1
Instead of using a BRE, that broke tests 30-32, 37-39, 42 at least with OpenBSD 6.7; use a simpler ERE. Fixes: d9f15d37f1 (pull: pass --autostash to merge, 2020-04-07) Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-10pull: pass --autostash to mergeLibravatar Denton Liu1-8/+35
Before, `--autostash` only worked with `git pull --rebase`. However, in the last patch, merge learned `--autostash` as well so there's no reason why we should have this restriction anymore. Teach pull to pass `--autostash` to merge, just like it did for rebase. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-10t5520: make test_pull_autostash() accept expect_parent_numLibravatar Denton Liu1-6/+8
Before, test_pull_autostash() was hardcoded to run `test_cmp_rev HEAD^ copy` to test that a rebase happened. However, in a future patch, we plan on testing merging as well. Make test_pull_autostash() accept a parent number as an argument so that, in the future, we can test if a merge happened in addition to a rebase. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16rebase: rename the two primary rebase backendsLibravatar Elijah Newren1-1/+1
Two related changes, with separate rationale for each: Rename the 'interactive' backend to 'merge' because: * 'interactive' as a name caused confusion; this backend has been used for many kinds of non-interactive rebases, and will probably be used in the future for more non-interactive rebases than interactive ones given that we are making it the default. * 'interactive' is not the underlying strategy; merging is. * the directory where state is stored is not called .git/rebase-interactive but .git/rebase-merge. Rename the 'am' backend to 'apply' because: * Few users are familiar with git-am as a reference point. * Related to the above, the name 'am' makes sentences in the documentation harder for users to read and comprehend (they may read it as the verb from "I am"); avoiding this difficult places a large burden on anyone writing documentation about this backend to be very careful with quoting and sentence structure and often forces annoying redundancy to try to avoid such problems. * Users stumble over pronunciation ("am" as in "I am a person not a backend" or "am" as in "the first and thirteenth letters in the alphabet in order are "A-M"); this may drive confusion when one user tries to explain to another what they are doing. * While "am" is the tool driving this backend, the tool driving git-am is git-apply, and since we are driving towards lower-level tools for the naming of the merge backend we may as well do so here too. * The directory where state is stored has never been called .git/rebase-am, it was always called .git/rebase-apply. For all the reasons listed above: * Modify the documentation to refer to the backends with the new names * Provide a brief note in the documentation connecting the new names to the old names in case users run across the old names anywhere (e.g. in old release notes or older versions of the documentation) * Change the (new) --am command line flag to --apply * Rename some enums, variables, and functions to reinforce the new backend names for us as well. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16rebase: change the default backend from "am" to "merge"Libravatar Elijah Newren1-4/+6
The am-backend drops information and thus limits what we can do: * lack of full tree information from the original commits means we cannot do directory rename detection and warn users that they might want to move some of their new files that they placed in old directories to prevent their becoming orphaned.[1] * reduction in context from only having a few lines beyond those changed means that when context lines are non-unique we can apply patches incorrectly.[2] * lack of access to original commits means that conflict marker annotation has less information available. * the am backend has safety problems with an ill-timed interrupt. Also, the merge/interactive backend have far more abilities, appear to currently have a slight performance advantage[3] and have room for more optimizations than the am backend[4] (and work is underway to take advantage of some of those possibilities). [1] https://lore.kernel.org/git/xmqqh8jeh1id.fsf@gitster-ct.c.googlers.com/ [2] https://lore.kernel.org/git/CABPp-BGiu2nVMQY_t-rnFR5GQUz_ipyEE8oDocKeO+h+t4Mn4A@mail.gmail.com/ [3] https://public-inbox.org/git/CABPp-BF=ev03WgODk6TMQmuNoatg2kiEe5DR__gJ0OTVqHSnfQ@mail.gmail.com/ [4] https://lore.kernel.org/git/CABPp-BGh7yW69QwxQb13K0HM38NKmQif3A6C6UULEKYnkEJ5vA@mail.gmail.com/ Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-16rebase tests: repeat some tests using the merge backend instead of amLibravatar Elijah Newren1-2/+15
In order to ensure the merge/interactive backend gets similar coverage to the am one, add some tests for cases where previously only the am backend was tested. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-21t5520: replace `! git` with `test_must_fail git`Libravatar Denton Liu1-2/+2
Currently, if a git command fails in an unexpected way, such as a segfault, it will be masked and ignored. Replace the ! with test_must_fail so that only expected failures pass. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-21t5520: remove redundant lines in test casesLibravatar Denton Liu1-8/+0
In the previous patches, the mechanical application of changes left some duplicate statements in the test case which were not strictly incorrect but were redundant and possibly misleading. Remove these duplicate statements so that it is clear that the intent behind the tests are that the content of the file stays the same throughout the whole test case. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-21t5520: replace $(cat ...) comparison with test_cmpLibravatar Denton Liu1-35/+70
We currently have many instances of `test <line> = $(cat <file>)` and `test $(cat <file>) = <line>`. In the case where this fails, it will be difficult for a developer to debug since the output will be masked. Replace these instances with invocations of test_cmp(). This change was done with the following GNU sed expressions: s/\(\s*\)test \([^=]*\)= "$(cat \([^)]*\))"/\1echo \2>expect \&\&\n\1test_cmp expect \3/ s/\(\s*\)test "$(cat \([^)]*\))" = \([^&]*\)\( &&\)\?$/\1echo \3 >expect \&\&\n\1test_cmp expect \2\4/ A future patch will clean up situations where we have multiple duplicate statements within a test case. This is done to keep this patch purely mechanical. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-21t5520: don't put git in upstream of pipeLibravatar Denton Liu1-1/+2
Before, if the invocation of git failed, it would be masked by the pipe since only the return code of the last element of a pipe is used. Rewrite the test to put the git command on its own line so its return code is not masked. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-21t5520: test single-line files by git with test_cmpLibravatar Denton Liu1-16/+48
In case an invocation of a git command fails within the command substitution, the failure will be masked. Replace the command substitution with a file-redirection and a call to test_cmp. This change was done with the following GNU sed expressions: s/\(\s*\)test \([^ ]*\) = "$(\(git [^)]*\))"/\1echo \2 >expect \&\&\n\1\3 >actual \&\&\n\1test_cmp expect actual/ s/\(\s*\)test "$(\(git [^)]*\))" = \([^ ]*\)/\1echo \3 >expect \&\&\n\1\2 >actual \&\&\n\1test_cmp expect actual/ A future patch will clean up situations where we have multiple duplicate statements within a test case. This is done to keep this patch purely mechanical. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-21t5520: use test_cmp_rev where possibleLibravatar Denton Liu1-25/+25
In case an invocation of `git rev-list` fails within the command substitution, the failure will be masked. Remove the command substitution and use test_cmp_rev() so that failures can be discovered. This change was done with the following sed expressions: s/test "$(git rev-parse.* \([^)]*\))" = "$(git rev-parse \([^)]*\))"/test_cmp_rev \1 \2/ s/test \([^ ]*\) = "$(git rev-parse.* \([^)]*\))"/test_cmp_rev \1 \2/ s/test "$(git rev-parse.* \([^)]*\))" != "$(git rev-parse.* \([^)]*\))"/test_cmp_rev ! \1 \2/ s/test \([^ ]*\) != "$(git rev-parse.* \([^)]*\))"/test_cmp_rev ! \1 \2/ Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-21t5520: replace test -{n,z} with test-lib functionsLibravatar Denton Liu1-4/+8
When wrapping a git command in a command substitution within another command, we throw away the git command's exit code. In case the git command fails, we would like to know about it rather than the failure being silent. Extract git commands so that their exit codes are not lost. Instead of using `test -n` or `test -z`, replace them respectively with invocations of test_file_not_empty() and test_must_be_empty() so that we get better debugging information in the case of a failure. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-21t5520: use test_line_count where possibleLibravatar Denton Liu1-1/+2
Instead of rolling our own functionality to test the number of lines a command outputs, use test_line_count() which provides better debugging information in the case of a failure. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-21t5520: remove spaces after redirect operatorLibravatar Denton Liu1-5/+5
The style for tests in Git is to have the redirect operator attached to the filename with no spaces. Fix test cases where this is not the case. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-21t5520: replace test -f with test-lib functionsLibravatar Denton Liu1-5/+5
Although `test -f` has the same functionality as test_path_is_file(), in the case where test_path_is_file() fails, we get much better debugging information. Replace `test -f` with test_path_is_file() so that future developers will have a better experience debugging these test cases. Also, in the case of `! test -f`, not only should that path not be a file, it shouldn't exist at all so replace it with test_path_is_missing(). Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-21t5520: let sed open its own inputLibravatar Denton Liu1-1/+1
We were using a redirection operator to feed input into sed. However, since sed is capable of opening its own files, make sed open its own files instead of redirecting input into it. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-21t5520: use sq for test case namesLibravatar Denton Liu1-2/+2
The usual convention is for test case names to be written between single-quotes. Change all double-quoted test case names to single-quotes except for two test case names that use variables within. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-21t5520: improve test styleLibravatar Denton Liu1-43/+45
Improve the test style by removing leading and trailing empty lines within test cases. Also, reformat multi-line subshells to conform to the existing style. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-11-02tests: optionally skip `git rebase -p` testsLibravatar Johannes Schindelin1-2/+4
The `--preserve-merges` mode of the `rebase` command is slated to be deprecated soon, as the more powerful `--rebase-merges` mode is available now, and the latter was designed with the express intent to address the shortcomings of `--preserve-merges`' design (e.g. the inability to reorder commits in an interactive rebase). As such, we will eventually even remove the `--preserve-merges` support, and along with it, its tests. In preparation for this, and also to allow the Windows phase of our automated tests to save some well-needed time when running the test suite, this commit introduces a new prerequisite REBASE_P, which can be forced to being unmet by setting the environment variable `GIT_TEST_SKIP_REBASE_P` to any non-empty string. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-17Merge branch 'js/pull-rebase-type-shorthand'Libravatar Junio C Hamano1-0/+12
"git pull --rebase=interactive" learned "i" as a short-hand for "interactive". * js/pull-rebase-type-shorthand: pull --rebase=<type>: allow single-letter abbreviations for the type
2018-08-06pull --rebase=<type>: allow single-letter abbreviations for the typeLibravatar Johannes Schindelin1-0/+12
Git for Windows' original 4aa8b8c8283 (Teach 'git pull' to handle --rebase=interactive, 2011-10-21) had support for the very convenient abbreviation git pull --rebase=i which was later lost when it was ported to the builtin `git pull`, and it was not introduced before the patch eventually made it into Git as f5eb87b98dd (pull: allow interactive rebase with --rebase=interactive, 2016-01-13). However, it is *really* a useful short hand for the occasional rebasing pull on branches that do not usually want to be rebased. So let's reintroduce this convenience, at long last. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-11has_uncommitted_changes(): fall back to empty treeLibravatar Jeff King1-0/+12
If has_uncommitted_changes() can't resolve HEAD (e.g., because it's unborn or corrupt), then we end up calling run_diff_index() with an empty revs.pending array. This causes a segfault, as run_diff_index() blindly looks at the first pending item. Fixing this raises a question of fault: should run_diff_index() handle this case, or is the caller wrong to pass an empty pending list? Looking at the other callers of run_diff_index(), they handle this in one of three ways: - they resolve the object themselves, and avoid doing the diff if it's not valid - they resolve the object themselves, and fall back to the empty tree - they use setup_revisions(), which will die() if the object isn't valid Since this is the only broken caller, that argues that the fix should go there. Falling back to the empty tree makes sense here, as we'd claim uncommitted changes if and only if the index is non-empty. This may be a little funny in the case of corruption (the corrupt HEAD probably _isn't_ empty), but: - we don't actually know the reason here that HEAD didn't resolve (the much more likely case is that we have an unborn HEAD, in which case the empty tree comparison is the right thing) - this matches how other code, like "git diff", behaves While we're thinking about it, let's add an assertion to run_diff_index(). It should always be passed a single object, and as this bug shows, it's easy to get it wrong (and an assertion is easier to hunt down than a segfault, or a quietly ignored extra tree). Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-17rebase: make resolve message clearer for inexperienced usersLibravatar William Duclot1-2/+2
The git UI can be improved by addressing the error messages to those they help: inexperienced and casual git users. To this intent, it is helpful to make sure the terms used in those messages can be understood by this segment of users, and that they guide them to resolve the problem. In particular, failure to apply a patch during a git rebase is a common problem that can be very destabilizing for the inexperienced user. It is important to lead them toward the resolution of the conflict (which is a 3-steps process, thus complex) and reassure them that they can escape a situation they can't handle with "--abort". This commit answer those two points by detailling the resolution process and by avoiding cryptic git linguo. Signed-off-by: William Duclot <william.duclot@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-01pull: ff --rebase --autostash works in dirty repoLibravatar Tyler Brazier1-0/+18
When `git pull --rebase --autostash` in a dirty repository resulted in a fast-forward, nothing was being autostashed and the pull failed. This was due to a shortcut to avoid running rebase when we can fast-forward, but autostash is ignored on that codepath. Now we will only take the shortcut if autostash is not in effect. Based on a few tests against the git.git repo, the shortcut does not seem to give us significant performance benefits, on Linux at least. Regardless, it is more important to be correct than to be fast. Signed-off-by: Tyler Brazier <tyler@tylerbrazier.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-19Merge branch 'jc/pull-rebase-ff'Libravatar Junio C Hamano1-0/+17
"git pull --rebase", when there is no new commits on our side since we forked from the upstream, should be able to fast-forward without invoking "git rebase", but it didn't. * jc/pull-rebase-ff: pull: fast-forward "pull --rebase=true"
2016-11-29pull: fast-forward "pull --rebase=true"Libravatar Junio C Hamano1-0/+17
"git pull --rebase" always runs "git rebase" after fetching the commit to serve as the new base, even when the new base is a descendant of the current HEAD, i.e. we haven't done any work. In such a case, we can instead fast-forward to the new base without invoking the rebase process. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-12t5520: become resilient to GETTEXT_POISONLibravatar Vasco Almeida1-2/+2
Use test_i18ngrep function instead of grep for grepping strings. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-26t5520: verify that `pull --rebase` shows the helpful advice when failingLibravatar Johannes Schindelin1-0/+32
It was noticed by Brendan Forster last October that the builtin `git am` regressed on that. Our hot fix reverted to spawning the recursive merge instead of using it as a library function. As we are about to revert that hot fix, after making the recursive merge a true library function (i.e. a function that does not die() in case of "normal" errors), let's add a test that verifies that we do not regress on the same problem which made the hot fix necessary in the first place. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-13Merge branch 'va/i18n-even-more'Libravatar Junio C Hamano1-1/+1
More markings of messages for i18n, with updates to various tests to pass GETTEXT_POISON tests. One patch from the original submission dropped due to conflicts with jk/upload-pack-hook, which is still in flux. * va/i18n-even-more: (38 commits) t5541: become resilient to GETTEXT_POISON i18n: branch: mark comment when editing branch description for translation i18n: unmark die messages for translation i18n: submodule: escape shell variables inside eval_gettext i18n: submodule: join strings marked for translation i18n: init-db: join message pieces i18n: remote: allow translations to reorder message i18n: remote: mark URL fallback text for translation i18n: standardise messages i18n: sequencer: add period to error message i18n: merge: change command option help to lowercase i18n: merge: mark messages for translation i18n: notes: mark options for translation i18n: notes: mark strings for translation i18n: transport-helper.c: change N_() call to _() i18n: bisect: mark strings for translation t5523: use test_i18ngrep for negation t4153: fix negated test_i18ngrep call t9003: become resilient to GETTEXT_POISON tests: unpack-trees: update to use test_i18n* functions ...
2016-06-17i18n: advice: internationalize message for conflictsLibravatar Vasco Almeida1-1/+1
Mark message for translation telling the user she has conflicts to resolve. Expose each particular use case, in order to enable translating entire sentences which would facilitate translating into other languages. Change "Pull" to lowercase to match other instances. Update test t5520-pull.sh, that relied on the old error message, to use the new one. Although we loose in source code conciseness, we would gain better translations because translators can 1) translate the entire sentence, including those terms concerning Git (committing, merging, etc) 2) have leeway to adapt to their languages. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-20pull: warn on --verify-signatures with --rebaseLibravatar Alexander Hirsch1-0/+16
git-pull silently ignores the --verify-signatures option when running --rebase, potentially leaving users in the belief that the rebase operation would check for valid GPG signatures. Implementing --verify-signatures for git-rebase was talked about, but doubts for a valid workflow rose up. Since you usually merge other's branches into your branch you might have an interest that their side has a valid GPG signature. Rebasing, on the other hand, is to rebuild your branch on top of other's work, in order to push the result back, and it is too late to reject their work even if you find their commits lack acceptable signature. Let's warn users that the --verify-signatures option is ignored during "pull --rebase"; users do not wonder what would happen if their commits lack acceptable signature that way. Signed-off-by: Alexander Hirsch <1zeeky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-04t5520: test --[no-]autostash with pull.rebase=trueLibravatar Mehul Jain1-0/+10
The "--[no-]autostash" options for git-pull are only valid in rebase mode (i.e. either --rebase is used or pull.rebase=true). Existing tests already check the cases when --rebase is used but fail to check for pull.rebase=true case. Add two new tests to check that the --[no-]autostash options work with pull.rebase=true. Signed-off-by: Mehul Jain <mehul.jain2029@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-04t5520: reduce commom lines of codeLibravatar Mehul Jain1-9/+7
These two tests are almost similar and thus can be folded in a for-loop. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Mehul Jain <mehul.jain2029@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-04t5520: factor out common "failing autostash" codeLibravatar Mehul Jain1-15/+11
Three tests contains repetitive lines of code. Factor out common code into test_pull_autostash_fail() and then call it in these tests. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Mehul Jain <mehul.jain2029@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-04t5520: factor out common "successful autostash" codeLibravatar Mehul Jain1-29/+15
Four tests contains repetitive lines of code. Factor out common code into test_pull_autostash() and then call it in these tests. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Mehul Jain <mehul.jain2029@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-04t5520: use better test to check stderr outputLibravatar Mehul Jain1-6/+4
Checking stderr output using test_i18ncmp may lead to test failure as some shells write trace output to stderr when run under 'set -x'. Use test_i18ngrep instead of test_i18ncmp. Signed-off-by: Mehul Jain <mehul.jain2029@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-04t5520: ensure consistent test conditionsLibravatar Mehul Jain1-0/+2
Test title says that tests are done with rebase.autostash unset, but does not take any action to make sure that it is indeed unset. This may lead to test failure if future changes somehow pollutes the configuration globally. Ensure consistent test conditions by explicitly unsetting rebase.autostash. Signed-off-by: Mehul Jain <mehul.jain2029@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-04t5520: use consistent capitalization in test titlesLibravatar Mehul Jain1-2/+2
Signed-off-by: Mehul Jain <mehul.jain2029@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-21pull --rebase: add --[no-]autostash flagLibravatar Mehul Jain1-0/+70
If rebase.autoStash configuration variable is set, there is no way to override it for "git pull --rebase" from the command line. Teach "git pull --rebase" the --[no-]autostash command line flag which overrides the current value of rebase.autoStash, if set. As "git rebase" understands the --[no-]autostash option, it's just a matter of passing the option to underlying "git rebase" when "git pull --rebase" is called. Helped-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Paul Tan <pyokagan@gmail.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Mehul Jain <mehul.jain2029@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-13pull: allow interactive rebase with --rebase=interactiveLibravatar Johannes Schindelin1-0/+10
A couple of years ago, I found the need to collaborate on topic branches that were rebased all the time, and I really needed to see what I was rebasing when pulling, so I introduced an interactively-rebasing pull. The way builtin pull works, this change also supports the value 'interactive' for the 'branch.<name>.rebase' config variable, which is a neat thing because users can now configure given branches for interactively-rebasing pulls without having to type out the complete `--rebase=interactive` option every time they pull. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-17Merge branch 'kd/pull-rebase-autostash'Libravatar Junio C Hamano1-0/+11
"git pull --rebase" has been taught to pay attention to rebase.autostash configuration. * kd/pull-rebase-autostash: pull: allow dirty tree when rebase.autostash enabled
2015-07-22pull: allow dirty tree when rebase.autostash enabledLibravatar Kevin Daudt1-0/+12
rebase learned to stash changes when it encounters a dirty work tree, but git pull --rebase does not. Only verify if the working tree is dirty when rebase.autostash is not enabled. Signed-off-by: Kevin Daudt <me@ikke.info> Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-02pull: handle git-fetch's options as wellLibravatar Paul Tan1-0/+20
While parsing the command-line arguments, git-pull stops parsing at the first unrecognized option, assuming that any subsequent options are for git-fetch, and can thus be kept in the shell's positional parameters list, so that it can be passed to git-fetch via the expansion of "$@". However, certain functions in git-pull assume that the positional parameters do not contain any options: * error_on_no_merge_candidates() uses the number of positional parameters to determine which error message to print out, and will thus print the wrong message if git-fetch's options are passed in as well. * the call to get_remote_merge_branch() assumes that the positional parameters only contains the optional repo and refspecs, and will thus silently fail if git-fetch's options are passed in as well. * --dry-run is a valid git-fetch option, but if provided after any git-fetch options, it is not recognized by git-pull and thus git-pull will continue to run the merge or rebase. Fix these bugs by teaching git-pull to parse git-fetch's options as well. Add tests to prevent regressions. This removes the limitation where git-fetch's options have to come after git-merge's and git-rebase's options on the command line. Update the documentation to reflect this. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-29t5520: check reflog action in fast-forward mergeLibravatar Paul Tan1-3/+10
When testing a fast-forward merge with git-pull, check to see if the reflog action is "pull" with the arguments passed to git-pull. While we are in the vicinity, remove the empty line as well. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-29t5520: test --rebase failure on unborn branch with indexLibravatar Paul Tan1-0/+15
Commit 19a7fcb (allow pull --rebase on branch yet to be born, 2009-08-11) special cases git-pull on an unborn branch in a different code path such that git-pull --rebase is still valid even though there is no HEAD yet. This code path still ensures that there is no index in order not to lose any staged changes. Implement a test to ensure that this check is triggered. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-29t5520: test --rebase with multiple branchesLibravatar Paul Tan1-0/+9
Since rebasing on top of multiple upstream branches does not make sense, since 51b2ead (disallow providing multiple upstream branches to rebase, pull --rebase, 2009-02-18), git-pull explicitly disallowed specifying multiple branches in the rebase case. Implement tests to ensure that git-pull fails and prints out the user-friendly error message in such a case. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-29t5520: test work tree fast-forward when fetch updates headLibravatar Paul Tan1-0/+21
Since b10ac50 (Fix pulling into the same branch., 2005-08-25), git-pull, upon detecting that git-fetch updated the current head, will fast-forward the working tree to the updated head commit. Implement tests to ensure that the fast-forward occurs in such a case, as well as to ensure that the user-friendly advice is printed upon failure. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-29t5520: test for failure if index has unresolved entriesLibravatar Paul Tan1-0/+19
Commit d38a30d (Be more user-friendly when refusing to do something because of conflict., 2010-01-12) introduced code paths to git-pull which will error out with user-friendly advices if the user is in the middle of a merge or has unmerged files. Implement tests to ensure that git-pull will not run, and will print these advices, if the user is in the middle of a merge or has unmerged files in the index. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-16 11:17:12 +0000