summaryrefslogtreecommitdiff
path: root/t/t5520-pull.sh
Commit message (Collapse)AuthorAgeFilesLines
* pull: ff --rebase --autostash works in dirty repotb/pull-ff-rebase-autostashTyler Brazier2017-06-011-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>
* Merge branch 'jc/pull-rebase-ff'Junio C Hamano2016-12-191-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"
| * pull: fast-forward "pull --rebase=true"jc/pull-rebase-ffJunio C Hamano2016-11-291-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>
* | t5520: become resilient to GETTEXT_POISONVasco Almeida2016-08-121-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>
* | t5520: verify that `pull --rebase` shows the helpful advice when failingJohannes Schindelin2016-07-261-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>
* | Merge branch 'va/i18n-even-more'Junio C Hamano2016-07-131-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 ...
| * | i18n: advice: internationalize message for conflictsVasco Almeida2016-06-171-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>
* | | pull: warn on --verify-signatures with --rebaseah/no-verify-signature-with-pull-rebaseAlexander Hirsch2016-05-201-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>
* | t5520: test --[no-]autostash with pull.rebase=truemj/pull-rebase-autostashMehul Jain2016-04-041-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>
* | t5520: reduce commom lines of codeMehul Jain2016-04-041-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>
* | t5520: factor out common "failing autostash" codeMehul Jain2016-04-041-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>
* | t5520: factor out common "successful autostash" codeMehul Jain2016-04-041-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>
* | t5520: use better test to check stderr outputMehul Jain2016-04-041-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>
* | t5520: ensure consistent test conditionsMehul Jain2016-04-041-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>
* | t5520: use consistent capitalization in test titlesMehul Jain2016-04-041-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>
* | pull --rebase: add --[no-]autostash flagMehul Jain2016-03-211-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>
* | pull: allow interactive rebase with --rebase=interactiveJohannes Schindelin2016-01-131-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>
* Merge branch 'kd/pull-rebase-autostash'Junio C Hamano2015-08-171-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
| * pull: allow dirty tree when rebase.autostash enabledkd/pull-rebase-autostashKevin Daudt2015-07-221-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>
* | pull: handle git-fetch's options as wellPaul Tan2015-06-021-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>
* | t5520: check reflog action in fast-forward mergept/pull-testsPaul Tan2015-05-291-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>
* | t5520: test --rebase failure on unborn branch with indexPaul Tan2015-05-291-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>
* | t5520: test --rebase with multiple branchesPaul Tan2015-05-291-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>
* | t5520: test work tree fast-forward when fetch updates headPaul Tan2015-05-291-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>
* | t5520: test for failure if index has unresolved entriesPaul Tan2015-05-291-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>
* | t5520: test no merge candidates casesPaul Tan2015-05-181-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a8c9bef (pull: improve advice for unconfigured error case, 2009-10-05) fully established the current advices given by git-pull for the different cases where git-fetch will not have anything marked for merge: 1. We fetched from a specific remote, and a refspec was given, but it ended up not fetching anything. This is usually because the user provided a wildcard refspec which had no matches on the remote end. 2. We fetched from a non-default remote, but didn't specify a branch to merge. We can't use the configured one because it applies to the default remote, and thus the user must specify the branches to merge. 3. We fetched from the branch's or repo's default remote, but: a. We are not on a branch, so there will never be a configured branch to merge with. b. We are on a branch, but there is no configured branch to merge with. 4. We fetched from the branch's or repo's default remote, but the configured branch to merge didn't get fetched (either it doesn't exist, or wasn't part of the configured fetch refspec) Implement tests for the above 5 cases to ensure that the correct code paths are triggered for each of these cases. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | t5520: prevent field splitting in content comparisonsPaul Tan2015-05-181-35/+35
|/ | | | | | | | | | | | | | | | | | | | | | | Many tests in t5520 used the following to test the contents of files: test `cat file` = expected or test $(cat file) = expected These 2 forms, however, will be affected by field splitting and, depending on the value of $IFS, may be split into multiple arguments, making the test fail in mysterious ways. Replace the above 2 forms with: test "$(cat file)" = expected as quoting the command substitution will prevent field splitting. Signed-off-by: Paul Tan <pyokagan@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t5520: test pulling an octopus into an unborn branchJunio C Hamano2015-04-291-0/+9
| | | | | | | | | | | | | | The code comment for "git merge" in builtin/merge.c, we say If the merged head is a valid one there is no reason to forbid "git merge" into a branch yet to be born. We do the same for "git pull". and t5520 does have an existing test for that behaviour. However, there was no test to make sure that 'git pull' to pull multiple branches into an unborn branch must fail. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t5520: style fixesJunio C Hamano2015-04-291-16/+6
| | | | | | | | | | Fix style funnies in early part of this test script that checks "git pull" into an unborn branch. The primary change is that 'chdir' to a newly created empty test repository is now protected by being done in a subshell to make it more robust without having to chdir back to the original place. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pull: allow pull to preserve merges when rebasingsh/pull-rebase-preserveStephen Haberman2013-09-041-0/+89
| | | | | | | | | | | | | | | | | | | If a user is working on master, and has merged in their feature branch, but now has to "git pull" because master moved, with pull.rebase their feature branch will be flattened into master. This is because "git pull" currently does not know about rebase's preserve merges flag, which would avoid this behavior, as it would instead replay just the merge commit of the feature branch onto the new master, and not replay each individual commit in the feature branch. Add a --rebase=preserve option, which will pass along --preserve-merges to rebase. Also add 'preserve' to the allowed values for the pull.rebase config setting. Signed-off-by: Stephen Haberman <stephen@exigencecorp.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jk/pull-into-dirty-unborn'Junio C Hamano2013-06-271-0/+29
|\ | | | | | | | | | | | | | | | | "git pull" into nothing trashed "local changes" that were in the index, and this avoids it. * jk/pull-into-dirty-unborn: pull: merge into unborn by fast-forwarding from empty tree pull: update unborn branch tip after index
| * pull: merge into unborn by fast-forwarding from empty treeThomas Rast2013-06-201-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic for pulling into an unborn branch was originally designed to be used on a newly-initialized repository (d09e79c, git-pull: allow pulling into an empty repository, 2006-11-16). It thus did not initially deal with uncommitted changes in the unborn branch. The case of an _unstaged_ untracked file was fixed by 4b3ffe5 (pull: do not clobber untracked files on initial pull, 2011-03-25). However, it still clobbered existing staged files, both when the file exists in the merged commit (it will be overwritten), and when it does not (it will be deleted). We fix this by doing a two-way merge, where the "current" side of the merge is an empty tree, and the "target" side is HEAD (already updated to FETCH_HEAD at this point). This amounts to claiming that all work in the index was done vs. an empty tree, and thus all content of the index is precious. Note that this use of read-tree just gives us protection against overwriting index and working tree changes. It will not actually result in a 3-way merge conflict in the index. This is fine, as this is a rare situation, and the conflict would not be interesting anyway (it must, by definition, be an add/add conflict with the whole content conflicting). And it makes it simpler for the user to recover, as they have no HEAD to "git reset" back to. Reported-by: Stefan Schüßler <mail@stefanschuessler.de> Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | t5520: use test_config to set/unset git config variables (leftover bits)Ramkumar Ramachandra2013-03-281-3/+3
| | | | | | | | | | | | | | | | | | Configuration from test_config does not last beyond the end of the current test assertion, making each test easier to think about in isolation. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | t5520: use test_config to set/unset git config variablesYann Droneaud2013-03-251-8/+4
|/ | | | | | | | | | | | Instead of using construct such as: test_when_finished "git config --unset <key>" git config <key> <value> uses test_config <key> <value> The latter takes care of removing <key> at the end of the test. Signed-off-by: Yann Droneaud <ydroneaud@opteya.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pull: introduce a pull.rebase option to enable --rebaseab/pull-rebase-configÆvar Arnfjörð Bjarmason2011-11-071-2/+21
| | | | | | | | | | | | | | | | | | | | | | Currently we either need to set branch.<name>.rebase for existing branches if we'd like "git pull" to mean "git pull --rebase", or have the forethought of setting "branch.autosetuprebase" before we create the branch. Introduce a "pull.rebase" option to globally configure "git pull" to mean "git pull --rebase" for any branch. This option will be considered at a lower priority than branch.<name>.rebase, i.e. we could set pull.rebase=true and branch.<name>.rebase=false and the latter configuration option would win. Reviewed-by: Sverre Rabbelier <srabbelier@gmail.com> Reviewed-by: Fernando Vezzosi <buccia@repnz.net> Reviewed-by: Eric Herman <eric@freesa.org> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Liked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pull: do not clobber untracked files on initial pullJeff King2011-03-251-0/+11
| | | | | | | | | | For a pull into an unborn branch, we do not use "git merge" at all. Instead, we call read-tree directly. However, we used the --reset parameter instead of "-m", which turns off the safety features. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Use reflog in 'pull --rebase . foo'Martin von Zweigbergk2010-11-291-0/+7
| | | | | | | | | | | | | Since c85c792 (pull --rebase: be cleverer with rebased upstream branches, 2008-01-26), "git pull --rebase" has used the reflog to try to rebase from the old upstream onto the new upstream. Make this work if the local repository is explicitly passed on the command line as in 'git pull --rebase . foo'. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Acked-by: Santi Béjar <santi@agolina.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'en/rebase-against-rebase-fix'Junio C Hamano2010-08-211-0/+62
|\ | | | | | | | | | | * en/rebase-against-rebase-fix: pull --rebase: Avoid spurious conflicts and reapplying unnecessary patches t5520-pull: Add testcases showing spurious conflicts from git pull --rebase
| * pull --rebase: Avoid spurious conflicts and reapplying unnecessary patchesElijah Newren2010-08-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to c85c792 (pull --rebase: be cleverer with rebased upstream branches, 2008-01-26), pull --rebase would run git rebase $merge_head which resulted in a call to git format-patch ... --ignore-if-in-upstream $merge_head..$cur_branch This resulted in patches from $merge_head..$cur_branch being applied, as long as they did not already exist in $cur_branch..$merge_head. Unfortunately, when upstream is rebased, $merge_head..$cur_branch also refers to "old" commits that have already been rebased upstream, meaning that many patches that were already fixed upstream would be reapplied. This could result in many spurious conflicts, as well as reintroduce patches that were intentionally dropped upstream. So the algorithm was changed in c85c792 (pull --rebase: be cleverer with rebased upstream branches, 2008-01-26) and d44e712 (pull: support rebased upstream + fetch + pull --rebase, 2009-07-19). Defining $old_remote_ref to be the most recent entry in the reflog for @{upstream} that is an ancestor of $cur_branch, pull --rebase was changed to run git rebase --onto $merge_head $old_remote_ref which results in a call to git format-patch ... --ignore-if-in-upstream $old_remote_ref..$cur_branch The whole point of this change was to reduce the number of commits being reapplied, by avoiding commits that upstream already has or had. In the rebased upstream case, this change achieved that purpose. It is worth noting, though, that since $old_remote_ref is always an ancestor of $cur_branch (by its definition), format-patch will not know what upstream is and thus will not be able to determine if any patches are already upstream; they will all be reapplied. In the non-rebased upstream case, this new form is usually the same as the original code but in some cases $old_remote_ref can be an ancestor of $(git merge-base $merge_head $cur_branch) meaning that instead of avoiding reapplying commits that upstream already has, it actually includes more such commits. Combined with the fact that format-patch can no longer detect commits that are already upstream (since it is no longer told what upstream is), results in lots of confusion for users (e.g. "git is giving me lots of conflicts in stuff I didn't even change since my last push.") Cases where additional commits could be reapplied include forking from a commit other than the tracking branch, or amending/rebasing after pushing. Cases where the inability to detect upstreamed commits cause problems include independent discovery of a fix and having your patches get upstreamed by some alternative route (e.g. pulling your changes to a third machine, pushing from there, and then going back to your original machine and trying to pull --rebase). Fix the non-rebased upstream case by ignoring $old_remote_ref whenever it is contained in $(git merge-base $merge_head $cur_branch). This should have no affect on the rebased upstream case. Acked-by: Santi Béjar <santi@agolina.net> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * t5520-pull: Add testcases showing spurious conflicts from git pull --rebaseElijah Newren2010-08-121-0/+62
| | | | | | | | | | Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | tests: use "test_cmp", not "diff", when verifying the resultGary V. Vaughan2010-05-311-1/+1
|/ | | | | | | | | | | In tests, call test_cmp rather than raw diff where possible (i.e. if the output does not go to a pipe), to allow the use of, say, 'cmp' when the default 'diff -u' is not compatible with a vendor diff. When that is not possible, use $DIFF, as set in GIT-BUILD-OPTIONS. Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* allow pull --rebase on branch yet to be bornJeff King2009-08-121-0/+11
| | | | | | | | | | | | | When doing a "pull --rebase", we check to make sure that the index and working tree are clean. The index-clean check compares the index against HEAD. The test erroneously reports dirtiness if we don't have a HEAD yet. In such an "unborn branch" case, by definition, a non-empty index won't be based on whatever we are pulling down from the remote, and will lose the local change. Just check if $GIT_DIR/index exists and error out. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pull: support rebased upstream + fetch + pull --rebaseSanti Béjar2009-07-191-3/+2
| | | | | | | | | | | | | | | | You cannot do a "git pull --rebase" with a rebased upstream, if you have already run "git fetch". Try to behave as if the "git fetch" was not run. In other words, find the fork point of the current branch, where the tip of upstream branch used to be, and use it as the upstream parameter of "git rebase". This patch computes the fork point by walking the reflog to find the first commit which is an ancestor of the current branch. Maybe there are smarter ways to compute it, but this is a straight forward implementation. Signed-off-by: Santi Béjar <santi@agolina.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* t5520-pull: Test for rebased upstream + fetch + pull --rebaseSanti Béjar2009-07-191-0/+14
| | | | | | | | | | | | | | If your upstream has rebased you can do: git pull --rebase but only if you haven't fetch before. Mark this case as test_expect_failure, in a later patch it will be changed to test_expect_success. Signed-off-by: Santi Béjar <santi@agolina.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* parse-remote: support default reflist in get_remote_merge_branchSanti Béjar2009-06-111-0/+14
| | | | | | | | | | | | Expand get_remote_merge_branch to compute the tracking branch to merge when called without arguments (or only the remote name). This allows "git pull --rebase" without arguments (default upstream branch) to work with a rebased upstream. With explicit arguments it already worked. Also add a test to check for this case. Signed-off-by: Santi Béjar <santi@agolina.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pull: allow "git pull origin $something:$current_branch" into an unborn branchJunio C Hamano2008-10-171-0/+12
| | | | | | | | | | | | | | | | | | Some misguided documents floating on the Net suggest this sequence: mkdir newdir && cd newdir git init git remote add origin $url git pull origin master:master "git pull" has known about misguided "pull" that lets the underlying fetch update the current branch for a long time. It also has known about "git pull origin master" into a branch yet to be born. These two workarounds however were not aware of the existence of each other and did not work well together. This fixes it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pull --rebase: exit early when the working directory is dirtyJohannes Schindelin2008-05-221-0/+18
| | | | | | | | | | | When rebasing fails during "pull --rebase", you cannot just clean up the working directory and call "pull --rebase" again, since the remote branch was already fetched. Therefore, die early when the working directory is dirty. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* pull --rebase: be cleverer with rebased upstream branchesJohannes Schindelin2008-01-261-0/+17
| | | | | | | | | When the upstream branch is tracked, we can detect if that branch was rebased since it was last fetched. Teach git to use that information to rebase from the old remote head onto the new remote head. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Teach 'git pull' about --rebaseJohannes Schindelin2007-11-281-0/+22
| | | | | | | | | | | | | | | | | | | | When calling 'git pull' with the '--rebase' option, it performs a fetch + rebase instead of a fetch + merge. This behavior is more desirable than fetch + pull when a topic branch is ready to be submitted and needs to be update. fetch + rebase might also be considered a better workflow with shared repositories in any case, or for contributors to a centrally managed repository, such as WINE's. As a convenience, you can set the default behavior for a branch by defining the config variable branch.<name>.rebase, which is interpreted as a bool. This setting can be overridden on the command line by --rebase and --no-rebase. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* War on whitespaceJunio C Hamano2007-06-071-1/+0
| | | | | | | | | This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano <gitster@pobox.com>
View Lorry Controller Status