2006-11-16 19:47:22 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='pulling into void'
|
|
|
|
|
2020-11-18 23:44:33 +00:00
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
|
tests: mark tests relying on the current default for `init.defaultBranch`
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-11-18 23:44:19 +00:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
2006-11-16 19:47:22 +00:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
2010-08-13 01:50:49 +00:00
|
|
|
modify () {
|
2019-11-12 23:07:52 +00:00
|
|
|
sed -e "$1" "$2" >"$2.x" &&
|
2010-08-13 01:50:49 +00:00
|
|
|
mv "$2.x" "$2"
|
|
|
|
}
|
|
|
|
|
2016-04-02 17:58:29 +00:00
|
|
|
test_pull_autostash () {
|
2020-04-07 14:28:08 +00:00
|
|
|
expect_parent_num="$1" &&
|
|
|
|
shift &&
|
2016-04-02 17:58:29 +00:00
|
|
|
git reset --hard before-rebase &&
|
|
|
|
echo dirty >new_file &&
|
|
|
|
git add new_file &&
|
|
|
|
git pull "$@" . copy &&
|
2020-04-07 14:28:08 +00:00
|
|
|
test_cmp_rev HEAD^"$expect_parent_num" copy &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo dirty >expect &&
|
|
|
|
test_cmp expect new_file &&
|
|
|
|
echo "modified again" >expect &&
|
|
|
|
test_cmp expect file
|
2016-04-02 17:58:29 +00:00
|
|
|
}
|
|
|
|
|
2016-04-02 17:58:30 +00:00
|
|
|
test_pull_autostash_fail () {
|
|
|
|
git reset --hard before-rebase &&
|
|
|
|
echo dirty >new_file &&
|
|
|
|
git add new_file &&
|
|
|
|
test_must_fail git pull "$@" . copy 2>err &&
|
2020-05-20 03:44:44 +00:00
|
|
|
test_i18ngrep -E "uncommitted changes.|overwritten by merge:" err
|
2016-04-02 17:58:30 +00:00
|
|
|
}
|
|
|
|
|
2006-11-16 19:47:22 +00:00
|
|
|
test_expect_success setup '
|
|
|
|
echo file >file &&
|
|
|
|
git add file &&
|
|
|
|
git commit -a -m original
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pulling into void' '
|
2015-04-23 20:29:14 +00:00
|
|
|
git init cloned &&
|
|
|
|
(
|
|
|
|
cd cloned &&
|
|
|
|
git pull ..
|
|
|
|
) &&
|
2019-11-12 23:07:55 +00:00
|
|
|
test_path_is_file file &&
|
|
|
|
test_path_is_file cloned/file &&
|
2010-05-14 09:31:37 +00:00
|
|
|
test_cmp file cloned/file
|
2006-11-16 19:47:22 +00:00
|
|
|
'
|
|
|
|
|
2020-11-18 23:44:33 +00:00
|
|
|
test_expect_success 'pulling into void using main:main' '
|
2015-04-23 20:29:14 +00:00
|
|
|
git init cloned-uho &&
|
2008-10-14 22:32:20 +00:00
|
|
|
(
|
|
|
|
cd cloned-uho &&
|
2020-11-18 23:44:33 +00:00
|
|
|
git pull .. main:main
|
2008-10-14 22:32:20 +00:00
|
|
|
) &&
|
2019-11-12 23:07:55 +00:00
|
|
|
test_path_is_file file &&
|
|
|
|
test_path_is_file cloned-uho/file &&
|
2008-10-14 22:32:20 +00:00
|
|
|
test_cmp file cloned-uho/file
|
|
|
|
'
|
|
|
|
|
2011-03-25 18:13:31 +00:00
|
|
|
test_expect_success 'pulling into void does not overwrite untracked files' '
|
|
|
|
git init cloned-untracked &&
|
|
|
|
(
|
|
|
|
cd cloned-untracked &&
|
|
|
|
echo untracked >file &&
|
2020-11-18 23:44:33 +00:00
|
|
|
test_must_fail git pull .. main &&
|
2011-03-25 18:13:31 +00:00
|
|
|
echo untracked >expect &&
|
|
|
|
test_cmp expect file
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
pull: merge into unborn by fast-forwarding from empty tree
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>
2013-06-20 22:38:28 +00:00
|
|
|
test_expect_success 'pulling into void does not overwrite staged files' '
|
|
|
|
git init cloned-staged-colliding &&
|
|
|
|
(
|
|
|
|
cd cloned-staged-colliding &&
|
|
|
|
echo "alternate content" >file &&
|
|
|
|
git add file &&
|
2020-11-18 23:44:33 +00:00
|
|
|
test_must_fail git pull .. main &&
|
pull: merge into unborn by fast-forwarding from empty tree
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>
2013-06-20 22:38:28 +00:00
|
|
|
echo "alternate content" >expect &&
|
|
|
|
test_cmp expect file &&
|
|
|
|
git cat-file blob :file >file.index &&
|
|
|
|
test_cmp expect file.index
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pulling into void does not remove new staged files' '
|
|
|
|
git init cloned-staged-new &&
|
|
|
|
(
|
|
|
|
cd cloned-staged-new &&
|
|
|
|
echo "new tracked file" >newfile &&
|
|
|
|
git add newfile &&
|
2020-11-18 23:44:33 +00:00
|
|
|
git pull .. main &&
|
pull: merge into unborn by fast-forwarding from empty tree
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>
2013-06-20 22:38:28 +00:00
|
|
|
echo "new tracked file" >expect &&
|
|
|
|
test_cmp expect newfile &&
|
|
|
|
git cat-file blob :newfile >newfile.index &&
|
|
|
|
test_cmp expect newfile.index
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
2015-04-23 20:34:08 +00:00
|
|
|
test_expect_success 'pulling into void must not create an octopus' '
|
|
|
|
git init cloned-octopus &&
|
|
|
|
(
|
|
|
|
cd cloned-octopus &&
|
2020-11-18 23:44:33 +00:00
|
|
|
test_must_fail git pull .. main main &&
|
2019-11-12 23:07:55 +00:00
|
|
|
test_path_is_missing file
|
2015-04-23 20:34:08 +00:00
|
|
|
)
|
|
|
|
'
|
|
|
|
|
git-fetch, git-branch: Support local --track via a special remote '.'
This patch adds support for a dummy remote '.' to avoid having
to declare a fake remote like
[remote "local"]
url = .
fetch = refs/heads/*:refs/heads/*
Such a builtin remote simplifies the operation of "git-fetch",
which will populate FETCH_HEAD but will not pretend that two
repositories are in use, will not create a thin pack, and will
not perform any useless remapping of names. The speed
improvement is around 20%, and it should improve more if
"git-fetch" is converted to a builtin.
To this end, git-parse-remote is grown with a new kind of
remote, 'builtin'. In git-fetch.sh, we treat the builtin remote
specially in that it needs no pack/store operations. In fact,
doing git-fetch on a builtin remote will simply populate
FETCH_HEAD appropriately.
The patch also improves of the --track/--no-track support,
extending it so that branch.<name>.remote items referring '.'
can be created. Finally, it fixes a typo in git-checkout.sh.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-15 08:23:20 +00:00
|
|
|
test_expect_success 'test . as a remote' '
|
2020-11-18 23:44:33 +00:00
|
|
|
git branch copy main &&
|
git-fetch, git-branch: Support local --track via a special remote '.'
This patch adds support for a dummy remote '.' to avoid having
to declare a fake remote like
[remote "local"]
url = .
fetch = refs/heads/*:refs/heads/*
Such a builtin remote simplifies the operation of "git-fetch",
which will populate FETCH_HEAD but will not pretend that two
repositories are in use, will not create a thin pack, and will
not perform any useless remapping of names. The speed
improvement is around 20%, and it should improve more if
"git-fetch" is converted to a builtin.
To this end, git-parse-remote is grown with a new kind of
remote, 'builtin'. In git-fetch.sh, we treat the builtin remote
specially in that it needs no pack/store operations. In fact,
doing git-fetch on a builtin remote will simply populate
FETCH_HEAD appropriately.
The patch also improves of the --track/--no-track support,
extending it so that branch.<name>.remote items referring '.'
can be created. Finally, it fixes a typo in git-checkout.sh.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-15 08:23:20 +00:00
|
|
|
git config branch.copy.remote . &&
|
2020-11-18 23:44:33 +00:00
|
|
|
git config branch.copy.merge refs/heads/main &&
|
git-fetch, git-branch: Support local --track via a special remote '.'
This patch adds support for a dummy remote '.' to avoid having
to declare a fake remote like
[remote "local"]
url = .
fetch = refs/heads/*:refs/heads/*
Such a builtin remote simplifies the operation of "git-fetch",
which will populate FETCH_HEAD but will not pretend that two
repositories are in use, will not create a thin pack, and will
not perform any useless remapping of names. The speed
improvement is around 20%, and it should improve more if
"git-fetch" is converted to a builtin.
To this end, git-parse-remote is grown with a new kind of
remote, 'builtin'. In git-fetch.sh, we treat the builtin remote
specially in that it needs no pack/store operations. In fact,
doing git-fetch on a builtin remote will simply populate
FETCH_HEAD appropriately.
The patch also improves of the --track/--no-track support,
extending it so that branch.<name>.remote items referring '.'
can be created. Finally, it fixes a typo in git-checkout.sh.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-15 08:23:20 +00:00
|
|
|
echo updated >file &&
|
|
|
|
git commit -a -m updated &&
|
|
|
|
git checkout copy &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect file &&
|
git-fetch, git-branch: Support local --track via a special remote '.'
This patch adds support for a dummy remote '.' to avoid having
to declare a fake remote like
[remote "local"]
url = .
fetch = refs/heads/*:refs/heads/*
Such a builtin remote simplifies the operation of "git-fetch",
which will populate FETCH_HEAD but will not pretend that two
repositories are in use, will not create a thin pack, and will
not perform any useless remapping of names. The speed
improvement is around 20%, and it should improve more if
"git-fetch" is converted to a builtin.
To this end, git-parse-remote is grown with a new kind of
remote, 'builtin'. In git-fetch.sh, we treat the builtin remote
specially in that it needs no pack/store operations. In fact,
doing git-fetch on a builtin remote will simply populate
FETCH_HEAD appropriately.
The patch also improves of the --track/--no-track support,
extending it so that branch.<name>.remote items referring '.'
can be created. Finally, it fixes a typo in git-checkout.sh.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-15 08:23:20 +00:00
|
|
|
git pull &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo updated >expect &&
|
|
|
|
test_cmp expect file &&
|
2015-05-29 11:44:45 +00:00
|
|
|
git reflog -1 >reflog.actual &&
|
|
|
|
sed "s/^[0-9a-f][0-9a-f]*/OBJID/" reflog.actual >reflog.fuzzy &&
|
|
|
|
echo "OBJID HEAD@{0}: pull: Fast-forward" >reflog.expected &&
|
|
|
|
test_cmp reflog.expected reflog.fuzzy
|
git-fetch, git-branch: Support local --track via a special remote '.'
This patch adds support for a dummy remote '.' to avoid having
to declare a fake remote like
[remote "local"]
url = .
fetch = refs/heads/*:refs/heads/*
Such a builtin remote simplifies the operation of "git-fetch",
which will populate FETCH_HEAD but will not pretend that two
repositories are in use, will not create a thin pack, and will
not perform any useless remapping of names. The speed
improvement is around 20%, and it should improve more if
"git-fetch" is converted to a builtin.
To this end, git-parse-remote is grown with a new kind of
remote, 'builtin'. In git-fetch.sh, we treat the builtin remote
specially in that it needs no pack/store operations. In fact,
doing git-fetch on a builtin remote will simply populate
FETCH_HEAD appropriately.
The patch also improves of the --track/--no-track support,
extending it so that branch.<name>.remote items referring '.'
can be created. Finally, it fixes a typo in git-checkout.sh.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-15 08:23:20 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'the default remote . should not break explicit pull' '
|
2020-11-18 23:44:33 +00:00
|
|
|
git checkout -b second main^ &&
|
git-fetch, git-branch: Support local --track via a special remote '.'
This patch adds support for a dummy remote '.' to avoid having
to declare a fake remote like
[remote "local"]
url = .
fetch = refs/heads/*:refs/heads/*
Such a builtin remote simplifies the operation of "git-fetch",
which will populate FETCH_HEAD but will not pretend that two
repositories are in use, will not create a thin pack, and will
not perform any useless remapping of names. The speed
improvement is around 20%, and it should improve more if
"git-fetch" is converted to a builtin.
To this end, git-parse-remote is grown with a new kind of
remote, 'builtin'. In git-fetch.sh, we treat the builtin remote
specially in that it needs no pack/store operations. In fact,
doing git-fetch on a builtin remote will simply populate
FETCH_HEAD appropriately.
The patch also improves of the --track/--no-track support,
extending it so that branch.<name>.remote items referring '.'
can be created. Finally, it fixes a typo in git-checkout.sh.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-15 08:23:20 +00:00
|
|
|
echo modified >file &&
|
|
|
|
git commit -a -m modified &&
|
|
|
|
git checkout copy &&
|
|
|
|
git reset --hard HEAD^ &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect file &&
|
2021-07-22 05:04:48 +00:00
|
|
|
git pull --no-rebase . second &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo modified >expect &&
|
|
|
|
test_cmp expect file &&
|
2015-05-29 11:44:45 +00:00
|
|
|
git reflog -1 >reflog.actual &&
|
|
|
|
sed "s/^[0-9a-f][0-9a-f]*/OBJID/" reflog.actual >reflog.fuzzy &&
|
2021-07-22 05:04:48 +00:00
|
|
|
echo "OBJID HEAD@{0}: pull --no-rebase . second: Fast-forward" >reflog.expected &&
|
2015-05-29 11:44:45 +00:00
|
|
|
test_cmp reflog.expected reflog.fuzzy
|
git-fetch, git-branch: Support local --track via a special remote '.'
This patch adds support for a dummy remote '.' to avoid having
to declare a fake remote like
[remote "local"]
url = .
fetch = refs/heads/*:refs/heads/*
Such a builtin remote simplifies the operation of "git-fetch",
which will populate FETCH_HEAD but will not pretend that two
repositories are in use, will not create a thin pack, and will
not perform any useless remapping of names. The speed
improvement is around 20%, and it should improve more if
"git-fetch" is converted to a builtin.
To this end, git-parse-remote is grown with a new kind of
remote, 'builtin'. In git-fetch.sh, we treat the builtin remote
specially in that it needs no pack/store operations. In fact,
doing git-fetch on a builtin remote will simply populate
FETCH_HEAD appropriately.
The patch also improves of the --track/--no-track support,
extending it so that branch.<name>.remote items referring '.'
can be created. Finally, it fixes a typo in git-checkout.sh.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-15 08:23:20 +00:00
|
|
|
'
|
|
|
|
|
t5520: test no merge candidates cases
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>
2015-05-18 13:32:52 +00:00
|
|
|
test_expect_success 'fail if wildcard spec does not match any refs' '
|
|
|
|
git checkout -b test copy^ &&
|
|
|
|
test_when_finished "git checkout -f copy && git branch -D test" &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect file &&
|
t5520: test no merge candidates cases
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>
2015-05-18 13:32:52 +00:00
|
|
|
test_must_fail git pull . "refs/nonexisting1/*:refs/nonexisting2/*" 2>err &&
|
|
|
|
test_i18ngrep "no candidates for merging" err &&
|
2019-11-12 23:08:12 +00:00
|
|
|
test_cmp expect file
|
t5520: test no merge candidates cases
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>
2015-05-18 13:32:52 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'fail if no branches specified with non-default remote' '
|
|
|
|
git remote add test_remote . &&
|
|
|
|
test_when_finished "git remote remove test_remote" &&
|
|
|
|
git checkout -b test copy^ &&
|
|
|
|
test_when_finished "git checkout -f copy && git branch -D test" &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect file &&
|
t5520: test no merge candidates cases
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>
2015-05-18 13:32:52 +00:00
|
|
|
test_config branch.test.remote origin &&
|
|
|
|
test_must_fail git pull test_remote 2>err &&
|
|
|
|
test_i18ngrep "specify a branch on the command line" err &&
|
2019-11-12 23:08:12 +00:00
|
|
|
test_cmp expect file
|
t5520: test no merge candidates cases
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>
2015-05-18 13:32:52 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'fail if not on a branch' '
|
|
|
|
git remote add origin . &&
|
|
|
|
test_when_finished "git remote remove origin" &&
|
|
|
|
git checkout HEAD^ &&
|
|
|
|
test_when_finished "git checkout -f copy" &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect file &&
|
t5520: test no merge candidates cases
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>
2015-05-18 13:32:52 +00:00
|
|
|
test_must_fail git pull 2>err &&
|
|
|
|
test_i18ngrep "not currently on a branch" err &&
|
2019-11-12 23:08:12 +00:00
|
|
|
test_cmp expect file
|
t5520: test no merge candidates cases
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>
2015-05-18 13:32:52 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'fail if no configuration for current branch' '
|
|
|
|
git remote add test_remote . &&
|
|
|
|
test_when_finished "git remote remove test_remote" &&
|
|
|
|
git checkout -b test copy^ &&
|
|
|
|
test_when_finished "git checkout -f copy && git branch -D test" &&
|
|
|
|
test_config branch.test.remote test_remote &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect file &&
|
t5520: test no merge candidates cases
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>
2015-05-18 13:32:52 +00:00
|
|
|
test_must_fail git pull 2>err &&
|
|
|
|
test_i18ngrep "no tracking information" err &&
|
2019-11-12 23:08:12 +00:00
|
|
|
test_cmp expect file
|
t5520: test no merge candidates cases
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>
2015-05-18 13:32:52 +00:00
|
|
|
'
|
|
|
|
|
2015-06-02 14:22:52 +00:00
|
|
|
test_expect_success 'pull --all: fail if no configuration for current branch' '
|
|
|
|
git remote add test_remote . &&
|
|
|
|
test_when_finished "git remote remove test_remote" &&
|
|
|
|
git checkout -b test copy^ &&
|
|
|
|
test_when_finished "git checkout -f copy && git branch -D test" &&
|
|
|
|
test_config branch.test.remote test_remote &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect file &&
|
2015-06-02 14:22:52 +00:00
|
|
|
test_must_fail git pull --all 2>err &&
|
|
|
|
test_i18ngrep "There is no tracking information" err &&
|
2019-11-12 23:08:12 +00:00
|
|
|
test_cmp expect file
|
2015-06-02 14:22:52 +00:00
|
|
|
'
|
|
|
|
|
t5520: test no merge candidates cases
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>
2015-05-18 13:32:52 +00:00
|
|
|
test_expect_success 'fail if upstream branch does not exist' '
|
|
|
|
git checkout -b test copy^ &&
|
|
|
|
test_when_finished "git checkout -f copy && git branch -D test" &&
|
|
|
|
test_config branch.test.remote . &&
|
|
|
|
test_config branch.test.merge refs/heads/nonexisting &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect file &&
|
t5520: test no merge candidates cases
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>
2015-05-18 13:32:52 +00:00
|
|
|
test_must_fail git pull 2>err &&
|
|
|
|
test_i18ngrep "no such ref was fetched" err &&
|
2019-11-12 23:08:12 +00:00
|
|
|
test_cmp expect file
|
t5520: test no merge candidates cases
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>
2015-05-18 13:32:52 +00:00
|
|
|
'
|
|
|
|
|
2015-05-29 11:44:40 +00:00
|
|
|
test_expect_success 'fail if the index has unresolved entries' '
|
|
|
|
git checkout -b third second^ &&
|
|
|
|
test_when_finished "git checkout -f copy && git branch -D third" &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect file &&
|
2015-05-29 11:44:40 +00:00
|
|
|
test_commit modified2 file &&
|
2019-11-12 23:08:02 +00:00
|
|
|
git ls-files -u >unmerged &&
|
|
|
|
test_must_be_empty unmerged &&
|
2021-07-22 05:04:48 +00:00
|
|
|
test_must_fail git pull --no-rebase . second &&
|
2019-11-12 23:08:02 +00:00
|
|
|
git ls-files -u >unmerged &&
|
|
|
|
test_file_not_empty unmerged &&
|
2015-05-29 11:44:40 +00:00
|
|
|
cp file expected &&
|
|
|
|
test_must_fail git pull . second 2>err &&
|
2016-06-17 20:20:52 +00:00
|
|
|
test_i18ngrep "Pulling is not possible because you have unmerged files." err &&
|
2015-05-29 11:44:40 +00:00
|
|
|
test_cmp expected file &&
|
|
|
|
git add file &&
|
2019-11-12 23:08:02 +00:00
|
|
|
git ls-files -u >unmerged &&
|
|
|
|
test_must_be_empty unmerged &&
|
2015-05-29 11:44:40 +00:00
|
|
|
test_must_fail git pull . second 2>err &&
|
|
|
|
test_i18ngrep "You have not concluded your merge" err &&
|
|
|
|
test_cmp expected file
|
|
|
|
'
|
|
|
|
|
2015-05-29 11:44:41 +00:00
|
|
|
test_expect_success 'fast-forwards working tree if branch head is updated' '
|
|
|
|
git checkout -b third second^ &&
|
|
|
|
test_when_finished "git checkout -f copy && git branch -D third" &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect file &&
|
2015-05-29 11:44:41 +00:00
|
|
|
git pull . second:third 2>err &&
|
|
|
|
test_i18ngrep "fetch updated the current branch head" err &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo modified >expect &&
|
|
|
|
test_cmp expect file &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev third second
|
2015-05-29 11:44:41 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'fast-forward fails with conflicting work tree' '
|
|
|
|
git checkout -b third second^ &&
|
|
|
|
test_when_finished "git checkout -f copy && git branch -D third" &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect file &&
|
2015-05-29 11:44:41 +00:00
|
|
|
echo conflict >file &&
|
|
|
|
test_must_fail git pull . second:third 2>err &&
|
|
|
|
test_i18ngrep "Cannot fast-forward your working tree" err &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo conflict >expect &&
|
|
|
|
test_cmp expect file &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev third second
|
2015-05-29 11:44:41 +00:00
|
|
|
'
|
|
|
|
|
2007-11-28 13:11:07 +00:00
|
|
|
test_expect_success '--rebase' '
|
|
|
|
git branch to-rebase &&
|
2019-11-12 23:07:58 +00:00
|
|
|
echo modified again >file &&
|
2007-11-28 13:11:07 +00:00
|
|
|
git commit -m file file &&
|
|
|
|
git checkout to-rebase &&
|
2019-11-12 23:07:58 +00:00
|
|
|
echo new >file2 &&
|
2007-11-28 13:11:07 +00:00
|
|
|
git add file2 &&
|
|
|
|
git commit -m "new file" &&
|
|
|
|
git tag before-rebase &&
|
|
|
|
git pull --rebase . copy &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev HEAD^ copy &&
|
2019-11-12 23:08:07 +00:00
|
|
|
echo new >expect &&
|
|
|
|
git show HEAD:file2 >actual &&
|
|
|
|
test_cmp expect actual
|
2007-11-28 13:11:07 +00:00
|
|
|
'
|
2015-05-29 11:44:42 +00:00
|
|
|
|
2020-02-15 21:36:38 +00:00
|
|
|
test_expect_success '--rebase (merge) fast forward' '
|
2016-06-29 17:22:31 +00:00
|
|
|
git reset --hard before-rebase &&
|
|
|
|
git checkout -b ff &&
|
|
|
|
echo another modification >file &&
|
|
|
|
git commit -m third file &&
|
|
|
|
|
|
|
|
git checkout to-rebase &&
|
2020-02-15 21:36:38 +00:00
|
|
|
git -c rebase.backend=merge pull --rebase . ff &&
|
|
|
|
test_cmp_rev HEAD ff &&
|
|
|
|
|
|
|
|
# The above only validates the result. Did we actually bypass rebase?
|
|
|
|
git reflog -1 >reflog.actual &&
|
|
|
|
sed "s/^[0-9a-f][0-9a-f]*/OBJID/" reflog.actual >reflog.fuzzy &&
|
|
|
|
echo "OBJID HEAD@{0}: pull --rebase . ff: Fast-forward" >reflog.expected &&
|
|
|
|
test_cmp reflog.expected reflog.fuzzy
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--rebase (am) fast forward' '
|
|
|
|
git reset --hard before-rebase &&
|
|
|
|
|
2020-02-15 21:36:41 +00:00
|
|
|
git -c rebase.backend=apply pull --rebase . ff &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev HEAD ff &&
|
2016-06-29 17:22:31 +00:00
|
|
|
|
|
|
|
# The above only validates the result. Did we actually bypass rebase?
|
|
|
|
git reflog -1 >reflog.actual &&
|
|
|
|
sed "s/^[0-9a-f][0-9a-f]*/OBJID/" reflog.actual >reflog.fuzzy &&
|
|
|
|
echo "OBJID HEAD@{0}: pull --rebase . ff: Fast-forward" >reflog.expected &&
|
|
|
|
test_cmp reflog.expected reflog.fuzzy
|
|
|
|
'
|
|
|
|
|
2017-06-01 04:18:36 +00:00
|
|
|
test_expect_success '--rebase --autostash fast forward' '
|
|
|
|
test_when_finished "
|
|
|
|
git reset --hard
|
|
|
|
git checkout to-rebase
|
|
|
|
git branch -D to-rebase-ff
|
|
|
|
git branch -D behind" &&
|
|
|
|
git branch behind &&
|
|
|
|
git checkout -b to-rebase-ff &&
|
|
|
|
echo another modification >>file &&
|
|
|
|
git add file &&
|
|
|
|
git commit -m mod &&
|
|
|
|
|
|
|
|
git checkout behind &&
|
|
|
|
echo dirty >file &&
|
|
|
|
git pull --rebase --autostash . to-rebase-ff &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev HEAD to-rebase-ff
|
2017-06-01 04:18:36 +00:00
|
|
|
'
|
|
|
|
|
2016-07-26 16:05:43 +00:00
|
|
|
test_expect_success '--rebase with conflicts shows advice' '
|
|
|
|
test_when_finished "git rebase --abort; git checkout -f to-rebase" &&
|
|
|
|
git checkout -b seq &&
|
|
|
|
test_seq 5 >seq.txt &&
|
|
|
|
git add seq.txt &&
|
|
|
|
test_tick &&
|
|
|
|
git commit -m "Add seq.txt" &&
|
|
|
|
echo 6 >>seq.txt &&
|
|
|
|
test_tick &&
|
|
|
|
git commit -m "Append to seq.txt" seq.txt &&
|
|
|
|
git checkout -b with-conflicts HEAD^ &&
|
|
|
|
echo conflicting >>seq.txt &&
|
|
|
|
test_tick &&
|
|
|
|
git commit -m "Create conflict" seq.txt &&
|
|
|
|
test_must_fail git pull --rebase . seq 2>err >out &&
|
2020-02-15 21:36:40 +00:00
|
|
|
test_i18ngrep "Resolve all conflicts manually" err
|
2016-07-26 16:05:43 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'failed --rebase shows advice' '
|
|
|
|
test_when_finished "git rebase --abort; git checkout -f to-rebase" &&
|
|
|
|
git checkout -b diverging &&
|
|
|
|
test_commit attributes .gitattributes "* text=auto" attrs &&
|
|
|
|
sha1="$(printf "1\\r\\n" | git hash-object -w --stdin)" &&
|
|
|
|
git update-index --cacheinfo 0644 $sha1 file &&
|
|
|
|
git commit -m v1-with-cr &&
|
|
|
|
# force checkout because `git reset --hard` will not leave clean `file`
|
|
|
|
git checkout -f -b fails-to-rebase HEAD^ &&
|
|
|
|
test_commit v2-without-cr file "2" file2-lf &&
|
|
|
|
test_must_fail git pull --rebase . diverging 2>err >out &&
|
2020-02-15 21:36:40 +00:00
|
|
|
test_i18ngrep "Resolve all conflicts manually" err
|
2016-07-26 16:05:43 +00:00
|
|
|
'
|
|
|
|
|
2015-05-29 11:44:42 +00:00
|
|
|
test_expect_success '--rebase fails with multiple branches' '
|
|
|
|
git reset --hard before-rebase &&
|
2020-11-18 23:44:33 +00:00
|
|
|
test_must_fail git pull --rebase . copy main 2>err &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev HEAD before-rebase &&
|
2015-05-29 11:44:42 +00:00
|
|
|
test_i18ngrep "Cannot rebase onto multiple branches" err &&
|
2019-11-12 23:08:07 +00:00
|
|
|
echo modified >expect &&
|
|
|
|
git show HEAD:file >actual &&
|
|
|
|
test_cmp expect actual
|
2015-05-29 11:44:42 +00:00
|
|
|
'
|
|
|
|
|
2015-07-04 21:42:38 +00:00
|
|
|
test_expect_success 'pull --rebase succeeds with dirty working directory and rebase.autostash set' '
|
|
|
|
test_config rebase.autostash true &&
|
2020-04-07 14:28:08 +00:00
|
|
|
test_pull_autostash 1 --rebase
|
2015-07-04 21:42:38 +00:00
|
|
|
'
|
|
|
|
|
2016-03-21 18:18:03 +00:00
|
|
|
test_expect_success 'pull --rebase --autostash & rebase.autostash=true' '
|
|
|
|
test_config rebase.autostash true &&
|
2020-04-07 14:28:08 +00:00
|
|
|
test_pull_autostash 1 --rebase --autostash
|
2016-03-21 18:18:03 +00:00
|
|
|
'
|
|
|
|
|
2016-04-02 17:58:26 +00:00
|
|
|
test_expect_success 'pull --rebase --autostash & rebase.autostash=false' '
|
2016-03-21 18:18:03 +00:00
|
|
|
test_config rebase.autostash false &&
|
2020-04-07 14:28:08 +00:00
|
|
|
test_pull_autostash 1 --rebase --autostash
|
2016-03-21 18:18:03 +00:00
|
|
|
'
|
|
|
|
|
2016-04-02 17:58:29 +00:00
|
|
|
test_expect_success 'pull --rebase --autostash & rebase.autostash unset' '
|
2016-04-02 17:58:27 +00:00
|
|
|
test_unconfig rebase.autostash &&
|
2020-04-07 14:28:08 +00:00
|
|
|
test_pull_autostash 1 --rebase --autostash
|
2016-03-21 18:18:03 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pull --rebase --no-autostash & rebase.autostash=true' '
|
|
|
|
test_config rebase.autostash true &&
|
2016-04-02 17:58:30 +00:00
|
|
|
test_pull_autostash_fail --rebase --no-autostash
|
2016-03-21 18:18:03 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pull --rebase --no-autostash & rebase.autostash=false' '
|
|
|
|
test_config rebase.autostash false &&
|
2016-04-02 17:58:30 +00:00
|
|
|
test_pull_autostash_fail --rebase --no-autostash
|
2016-03-21 18:18:03 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pull --rebase --no-autostash & rebase.autostash unset' '
|
2016-04-02 17:58:27 +00:00
|
|
|
test_unconfig rebase.autostash &&
|
2016-04-02 17:58:30 +00:00
|
|
|
test_pull_autostash_fail --rebase --no-autostash
|
2016-03-21 18:18:03 +00:00
|
|
|
'
|
|
|
|
|
2020-04-07 14:28:09 +00:00
|
|
|
test_expect_success 'pull succeeds with dirty working directory and merge.autostash set' '
|
|
|
|
test_config merge.autostash true &&
|
2021-07-22 05:04:48 +00:00
|
|
|
test_pull_autostash 2 --no-rebase
|
2020-04-07 14:28:09 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pull --autostash & merge.autostash=true' '
|
|
|
|
test_config merge.autostash true &&
|
2021-07-22 05:04:48 +00:00
|
|
|
test_pull_autostash 2 --autostash --no-rebase
|
2020-04-07 14:28:09 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pull --autostash & merge.autostash=false' '
|
|
|
|
test_config merge.autostash false &&
|
2021-07-22 05:04:48 +00:00
|
|
|
test_pull_autostash 2 --autostash --no-rebase
|
2020-04-07 14:28:09 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pull --autostash & merge.autostash unset' '
|
|
|
|
test_unconfig merge.autostash &&
|
2021-07-22 05:04:48 +00:00
|
|
|
test_pull_autostash 2 --autostash --no-rebase
|
2020-04-07 14:28:09 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pull --no-autostash & merge.autostash=true' '
|
|
|
|
test_config merge.autostash true &&
|
2021-07-22 05:04:48 +00:00
|
|
|
test_pull_autostash_fail --no-autostash --no-rebase
|
2020-04-07 14:28:09 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pull --no-autostash & merge.autostash=false' '
|
|
|
|
test_config merge.autostash false &&
|
2021-07-22 05:04:48 +00:00
|
|
|
test_pull_autostash_fail --no-autostash --no-rebase
|
2020-04-07 14:28:09 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pull --no-autostash & merge.autostash unset' '
|
|
|
|
test_unconfig merge.autostash &&
|
2021-07-22 05:04:48 +00:00
|
|
|
test_pull_autostash_fail --no-autostash --no-rebase
|
2020-04-07 14:28:09 +00:00
|
|
|
'
|
2016-03-21 18:18:03 +00:00
|
|
|
|
2011-11-06 09:50:10 +00:00
|
|
|
test_expect_success 'pull.rebase' '
|
|
|
|
git reset --hard before-rebase &&
|
2013-03-24 21:06:07 +00:00
|
|
|
test_config pull.rebase true &&
|
2011-11-06 09:50:10 +00:00
|
|
|
git pull . copy &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev HEAD^ copy &&
|
2019-11-12 23:08:07 +00:00
|
|
|
echo new >expect &&
|
|
|
|
git show HEAD:file2 >actual &&
|
|
|
|
test_cmp expect actual
|
2011-11-06 09:50:10 +00:00
|
|
|
'
|
2007-11-28 13:11:07 +00:00
|
|
|
|
2016-04-02 17:58:32 +00:00
|
|
|
test_expect_success 'pull --autostash & pull.rebase=true' '
|
|
|
|
test_config pull.rebase true &&
|
2020-04-07 14:28:08 +00:00
|
|
|
test_pull_autostash 1 --autostash
|
2016-04-02 17:58:32 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pull --no-autostash & pull.rebase=true' '
|
|
|
|
test_config pull.rebase true &&
|
|
|
|
test_pull_autostash_fail --no-autostash
|
|
|
|
'
|
|
|
|
|
2007-11-28 13:11:07 +00:00
|
|
|
test_expect_success 'branch.to-rebase.rebase' '
|
|
|
|
git reset --hard before-rebase &&
|
2013-03-24 21:06:07 +00:00
|
|
|
test_config branch.to-rebase.rebase true &&
|
2007-11-28 13:11:07 +00:00
|
|
|
git pull . copy &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev HEAD^ copy &&
|
2019-11-12 23:08:07 +00:00
|
|
|
echo new >expect &&
|
|
|
|
git show HEAD:file2 >actual &&
|
|
|
|
test_cmp expect actual
|
2007-11-28 13:11:07 +00:00
|
|
|
'
|
|
|
|
|
2011-11-06 09:50:10 +00:00
|
|
|
test_expect_success 'branch.to-rebase.rebase should override pull.rebase' '
|
|
|
|
git reset --hard before-rebase &&
|
2013-03-24 21:06:07 +00:00
|
|
|
test_config pull.rebase true &&
|
|
|
|
test_config branch.to-rebase.rebase false &&
|
2011-11-06 09:50:10 +00:00
|
|
|
git pull . copy &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev ! HEAD^ copy &&
|
2019-11-12 23:08:07 +00:00
|
|
|
echo new >expect &&
|
|
|
|
git show HEAD:file2 >actual &&
|
|
|
|
test_cmp expect actual
|
2011-11-06 09:50:10 +00:00
|
|
|
'
|
|
|
|
|
2019-11-12 23:07:50 +00:00
|
|
|
test_expect_success 'pull --rebase warns on --verify-signatures' '
|
2016-05-20 21:00:54 +00:00
|
|
|
git reset --hard before-rebase &&
|
|
|
|
git pull --rebase --verify-signatures . copy 2>err &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev HEAD^ copy &&
|
2019-11-12 23:08:07 +00:00
|
|
|
echo new >expect &&
|
|
|
|
git show HEAD:file2 >actual &&
|
|
|
|
test_cmp expect actual &&
|
2016-05-20 21:00:54 +00:00
|
|
|
test_i18ngrep "ignoring --verify-signatures for rebase" err
|
|
|
|
'
|
|
|
|
|
2019-11-12 23:07:50 +00:00
|
|
|
test_expect_success 'pull --rebase does not warn on --no-verify-signatures' '
|
2016-05-20 21:00:54 +00:00
|
|
|
git reset --hard before-rebase &&
|
|
|
|
git pull --rebase --no-verify-signatures . copy 2>err &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev HEAD^ copy &&
|
2019-11-12 23:08:07 +00:00
|
|
|
echo new >expect &&
|
|
|
|
git show HEAD:file2 >actual &&
|
|
|
|
test_cmp expect actual &&
|
2016-05-20 21:00:54 +00:00
|
|
|
test_i18ngrep ! "verify-signatures" err
|
|
|
|
'
|
|
|
|
|
2020-11-18 23:44:33 +00:00
|
|
|
# add a feature branch, keep-merge, that is merged into main, so the
|
2013-08-13 03:43:42 +00:00
|
|
|
# test can try preserving the merge commit (or not) with various
|
|
|
|
# --rebase flags/pull.rebase settings.
|
|
|
|
test_expect_success 'preserve merge setup' '
|
|
|
|
git reset --hard before-rebase &&
|
|
|
|
git checkout -b keep-merge second^ &&
|
|
|
|
test_commit file3 &&
|
|
|
|
git checkout to-rebase &&
|
|
|
|
git merge keep-merge &&
|
|
|
|
git tag before-preserve-rebase
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pull.rebase=false create a new merge commit' '
|
|
|
|
git reset --hard before-preserve-rebase &&
|
|
|
|
test_config pull.rebase false &&
|
|
|
|
git pull . copy &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev HEAD^1 before-preserve-rebase &&
|
|
|
|
test_cmp_rev HEAD^2 copy &&
|
2019-11-12 23:08:07 +00:00
|
|
|
echo file3 >expect &&
|
|
|
|
git show HEAD:file3.t >actual &&
|
|
|
|
test_cmp expect actual
|
2013-08-13 03:43:42 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pull.rebase=true flattens keep-merge' '
|
|
|
|
git reset --hard before-preserve-rebase &&
|
|
|
|
test_config pull.rebase true &&
|
|
|
|
git pull . copy &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev HEAD^^ copy &&
|
2019-11-12 23:08:07 +00:00
|
|
|
echo file3 >expect &&
|
|
|
|
git show HEAD:file3.t >actual &&
|
|
|
|
test_cmp expect actual
|
2013-08-13 03:43:42 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'pull.rebase=1 is treated as true and flattens keep-merge' '
|
|
|
|
git reset --hard before-preserve-rebase &&
|
|
|
|
test_config pull.rebase 1 &&
|
|
|
|
git pull . copy &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev HEAD^^ copy &&
|
2019-11-12 23:08:07 +00:00
|
|
|
echo file3 >expect &&
|
|
|
|
git show HEAD:file3.t >actual &&
|
|
|
|
test_cmp expect actual
|
2013-08-13 03:43:42 +00:00
|
|
|
'
|
|
|
|
|
2016-01-13 12:17:15 +00:00
|
|
|
test_expect_success 'pull.rebase=interactive' '
|
|
|
|
write_script "$TRASH_DIRECTORY/fake-editor" <<-\EOF &&
|
|
|
|
echo I was here >fake.out &&
|
|
|
|
false
|
|
|
|
EOF
|
|
|
|
test_set_editor "$TRASH_DIRECTORY/fake-editor" &&
|
2018-08-04 19:23:09 +00:00
|
|
|
test_when_finished "test_might_fail git rebase --abort" &&
|
2016-01-13 12:17:15 +00:00
|
|
|
test_must_fail git pull --rebase=interactive . copy &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo "I was here" >expect &&
|
|
|
|
test_cmp expect fake.out
|
2016-01-13 12:17:15 +00:00
|
|
|
'
|
|
|
|
|
2018-08-04 19:23:09 +00:00
|
|
|
test_expect_success 'pull --rebase=i' '
|
|
|
|
write_script "$TRASH_DIRECTORY/fake-editor" <<-\EOF &&
|
|
|
|
echo I was here, too >fake.out &&
|
|
|
|
false
|
|
|
|
EOF
|
|
|
|
test_set_editor "$TRASH_DIRECTORY/fake-editor" &&
|
|
|
|
test_when_finished "test_might_fail git rebase --abort" &&
|
|
|
|
test_must_fail git pull --rebase=i . copy &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo "I was here, too" >expect &&
|
|
|
|
test_cmp expect fake.out
|
2018-08-04 19:23:09 +00:00
|
|
|
'
|
|
|
|
|
2013-08-13 03:43:42 +00:00
|
|
|
test_expect_success 'pull.rebase=invalid fails' '
|
|
|
|
git reset --hard before-preserve-rebase &&
|
|
|
|
test_config pull.rebase invalid &&
|
2019-11-12 23:08:16 +00:00
|
|
|
test_must_fail git pull . copy
|
2013-08-13 03:43:42 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--rebase=false create a new merge commit' '
|
|
|
|
git reset --hard before-preserve-rebase &&
|
|
|
|
test_config pull.rebase true &&
|
|
|
|
git pull --rebase=false . copy &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev HEAD^1 before-preserve-rebase &&
|
|
|
|
test_cmp_rev HEAD^2 copy &&
|
2019-11-12 23:08:07 +00:00
|
|
|
echo file3 >expect &&
|
|
|
|
git show HEAD:file3.t >actual &&
|
|
|
|
test_cmp expect actual
|
2013-08-13 03:43:42 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--rebase=true rebases and flattens keep-merge' '
|
|
|
|
git reset --hard before-preserve-rebase &&
|
2021-09-07 21:05:02 +00:00
|
|
|
test_config pull.rebase merges &&
|
2013-08-13 03:43:42 +00:00
|
|
|
git pull --rebase=true . copy &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev HEAD^^ copy &&
|
2019-11-12 23:08:07 +00:00
|
|
|
echo file3 >expect &&
|
|
|
|
git show HEAD:file3.t >actual &&
|
|
|
|
test_cmp expect actual
|
2013-08-13 03:43:42 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--rebase=invalid fails' '
|
|
|
|
git reset --hard before-preserve-rebase &&
|
2019-11-12 23:08:16 +00:00
|
|
|
test_must_fail git pull --rebase=invalid . copy
|
2013-08-13 03:43:42 +00:00
|
|
|
'
|
|
|
|
|
2021-09-07 21:05:02 +00:00
|
|
|
test_expect_success '--rebase overrides pull.rebase=merges and flattens keep-merge' '
|
2013-08-13 03:43:42 +00:00
|
|
|
git reset --hard before-preserve-rebase &&
|
2021-09-07 21:05:02 +00:00
|
|
|
test_config pull.rebase merges &&
|
2013-08-13 03:43:42 +00:00
|
|
|
git pull --rebase . copy &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev HEAD^^ copy &&
|
2019-11-12 23:08:07 +00:00
|
|
|
echo file3 >expect &&
|
|
|
|
git show HEAD:file3.t >actual &&
|
|
|
|
test_cmp expect actual
|
2013-08-13 03:43:42 +00:00
|
|
|
'
|
|
|
|
|
2008-01-26 18:04:37 +00:00
|
|
|
test_expect_success '--rebase with rebased upstream' '
|
|
|
|
git remote add -f me . &&
|
|
|
|
git checkout copy &&
|
2009-06-11 22:39:19 +00:00
|
|
|
git tag copy-orig &&
|
2008-01-26 18:04:37 +00:00
|
|
|
git reset --hard HEAD^ &&
|
2019-11-12 23:07:58 +00:00
|
|
|
echo conflicting modification >file &&
|
2008-01-26 18:04:37 +00:00
|
|
|
git commit -m conflict file &&
|
|
|
|
git checkout to-rebase &&
|
2019-11-12 23:07:58 +00:00
|
|
|
echo file >file2 &&
|
2008-01-26 18:04:37 +00:00
|
|
|
git commit -m to-rebase file2 &&
|
2009-06-11 22:39:19 +00:00
|
|
|
git tag to-rebase-orig &&
|
2008-01-26 18:04:37 +00:00
|
|
|
git pull --rebase me copy &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo "conflicting modification" >expect &&
|
|
|
|
test_cmp expect file &&
|
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect file2
|
2008-01-26 18:04:37 +00:00
|
|
|
'
|
|
|
|
|
2015-06-02 14:22:52 +00:00
|
|
|
test_expect_success '--rebase -f with rebased upstream' '
|
|
|
|
test_when_finished "test_might_fail git rebase --abort" &&
|
|
|
|
git reset --hard to-rebase-orig &&
|
|
|
|
git pull --rebase -f me copy &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo "conflicting modification" >expect &&
|
|
|
|
test_cmp expect file &&
|
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect file2
|
2015-06-02 14:22:52 +00:00
|
|
|
'
|
|
|
|
|
2009-06-11 22:39:19 +00:00
|
|
|
test_expect_success '--rebase with rebased default upstream' '
|
|
|
|
git update-ref refs/remotes/me/copy copy-orig &&
|
|
|
|
git checkout --track -b to-rebase2 me/copy &&
|
|
|
|
git reset --hard to-rebase-orig &&
|
|
|
|
git pull --rebase &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo "conflicting modification" >expect &&
|
|
|
|
test_cmp expect file &&
|
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect file2
|
2009-06-11 22:39:19 +00:00
|
|
|
'
|
|
|
|
|
2009-07-19 07:45:16 +00:00
|
|
|
test_expect_success 'rebased upstream + fetch + pull --rebase' '
|
2009-07-16 00:09:14 +00:00
|
|
|
|
|
|
|
git update-ref refs/remotes/me/copy copy-orig &&
|
|
|
|
git reset --hard to-rebase-orig &&
|
|
|
|
git checkout --track -b to-rebase3 me/copy &&
|
|
|
|
git reset --hard to-rebase-orig &&
|
|
|
|
git fetch &&
|
2009-07-19 07:45:16 +00:00
|
|
|
git pull --rebase &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo "conflicting modification" >expect &&
|
|
|
|
test_cmp expect file &&
|
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect file2
|
2009-07-16 00:09:14 +00:00
|
|
|
|
|
|
|
'
|
|
|
|
|
2008-05-21 11:32:16 +00:00
|
|
|
test_expect_success 'pull --rebase dies early with dirty working directory' '
|
2009-06-11 22:39:19 +00:00
|
|
|
git checkout to-rebase &&
|
2008-05-21 11:32:16 +00:00
|
|
|
git update-ref refs/remotes/me/copy copy^ &&
|
2015-05-18 13:32:51 +00:00
|
|
|
COPY="$(git rev-parse --verify me/copy)" &&
|
2008-05-21 11:32:16 +00:00
|
|
|
git rebase --onto $COPY copy &&
|
2013-03-28 12:40:19 +00:00
|
|
|
test_config branch.to-rebase.remote me &&
|
|
|
|
test_config branch.to-rebase.merge refs/heads/copy &&
|
|
|
|
test_config branch.to-rebase.rebase true &&
|
2019-11-12 23:07:58 +00:00
|
|
|
echo dirty >>file &&
|
2008-05-21 11:32:16 +00:00
|
|
|
git add file &&
|
|
|
|
test_must_fail git pull &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev "$COPY" me/copy &&
|
2008-05-21 11:32:16 +00:00
|
|
|
git checkout HEAD -- file &&
|
|
|
|
git pull &&
|
2019-11-12 23:08:05 +00:00
|
|
|
test_cmp_rev ! "$COPY" me/copy
|
2008-05-21 11:32:16 +00:00
|
|
|
'
|
|
|
|
|
2009-08-12 03:27:40 +00:00
|
|
|
test_expect_success 'pull --rebase works on branch yet to be born' '
|
2020-11-18 23:44:33 +00:00
|
|
|
git rev-parse main >expect &&
|
2009-08-12 03:27:40 +00:00
|
|
|
mkdir empty_repo &&
|
2019-11-12 23:07:48 +00:00
|
|
|
(
|
|
|
|
cd empty_repo &&
|
|
|
|
git init &&
|
2020-11-18 23:44:33 +00:00
|
|
|
git pull --rebase .. main &&
|
2019-11-12 23:07:48 +00:00
|
|
|
git rev-parse HEAD >../actual
|
2009-08-12 03:27:40 +00:00
|
|
|
) &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2015-05-29 11:44:43 +00:00
|
|
|
test_expect_success 'pull --rebase fails on unborn branch with staged changes' '
|
|
|
|
test_when_finished "rm -rf empty_repo2" &&
|
|
|
|
git init empty_repo2 &&
|
|
|
|
(
|
|
|
|
cd empty_repo2 &&
|
|
|
|
echo staged-file >staged-file &&
|
|
|
|
git add staged-file &&
|
2019-11-12 23:08:07 +00:00
|
|
|
echo staged-file >expect &&
|
|
|
|
git ls-files >actual &&
|
|
|
|
test_cmp expect actual &&
|
2020-11-18 23:44:33 +00:00
|
|
|
test_must_fail git pull --rebase .. main 2>err &&
|
2019-11-12 23:08:07 +00:00
|
|
|
git ls-files >actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
git show :staged-file >actual &&
|
|
|
|
test_cmp expect actual &&
|
2015-05-29 11:44:43 +00:00
|
|
|
test_i18ngrep "unborn branch with changes added to the index" err
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
has_uncommitted_changes(): fall back to empty tree
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>
2018-07-11 14:14:06 +00:00
|
|
|
test_expect_success 'pull --rebase fails on corrupt HEAD' '
|
|
|
|
test_when_finished "rm -rf corrupt" &&
|
|
|
|
git init corrupt &&
|
|
|
|
(
|
|
|
|
cd corrupt &&
|
|
|
|
test_commit one &&
|
2019-11-12 23:08:10 +00:00
|
|
|
git rev-parse --verify HEAD >head &&
|
|
|
|
obj=$(sed "s#^..#&/#" head) &&
|
has_uncommitted_changes(): fall back to empty tree
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>
2018-07-11 14:14:06 +00:00
|
|
|
rm -f .git/objects/$obj &&
|
|
|
|
test_must_fail git pull --rebase
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
2010-08-13 01:50:49 +00:00
|
|
|
test_expect_success 'setup for detecting upstreamed changes' '
|
2021-05-10 14:19:06 +00:00
|
|
|
test_create_repo src &&
|
|
|
|
test_commit -C src --printf one stuff "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n" &&
|
2010-08-13 01:50:49 +00:00
|
|
|
git clone src dst &&
|
2019-11-12 23:07:48 +00:00
|
|
|
(
|
|
|
|
cd src &&
|
|
|
|
modify s/5/43/ stuff &&
|
|
|
|
git commit -a -m "5->43" &&
|
|
|
|
modify s/6/42/ stuff &&
|
|
|
|
git commit -a -m "Make it bigger"
|
2010-08-13 01:50:49 +00:00
|
|
|
) &&
|
2019-11-12 23:07:48 +00:00
|
|
|
(
|
|
|
|
cd dst &&
|
|
|
|
modify s/5/43/ stuff &&
|
|
|
|
git commit -a -m "Independent discovery of 5->43"
|
2010-08-13 01:50:49 +00:00
|
|
|
)
|
|
|
|
'
|
|
|
|
|
pull --rebase: Avoid spurious conflicts and reapplying unnecessary patches
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>
2010-08-13 01:50:50 +00:00
|
|
|
test_expect_success 'git pull --rebase detects upstreamed changes' '
|
2019-11-12 23:07:48 +00:00
|
|
|
(
|
|
|
|
cd dst &&
|
|
|
|
git pull --rebase &&
|
2019-11-12 23:08:02 +00:00
|
|
|
git ls-files -u >untracked &&
|
|
|
|
test_must_be_empty untracked
|
2010-08-13 01:50:49 +00:00
|
|
|
)
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'setup for avoiding reapplying old patches' '
|
2019-11-12 23:07:48 +00:00
|
|
|
(
|
|
|
|
cd dst &&
|
|
|
|
test_might_fail git rebase --abort &&
|
2020-11-18 23:44:33 +00:00
|
|
|
git reset --hard origin/main
|
2010-08-13 01:50:49 +00:00
|
|
|
) &&
|
|
|
|
git clone --bare src src-replace.git &&
|
|
|
|
rm -rf src &&
|
|
|
|
mv src-replace.git src &&
|
2019-11-12 23:07:48 +00:00
|
|
|
(
|
|
|
|
cd dst &&
|
|
|
|
modify s/2/22/ stuff &&
|
|
|
|
git commit -a -m "Change 2" &&
|
|
|
|
modify s/3/33/ stuff &&
|
|
|
|
git commit -a -m "Change 3" &&
|
|
|
|
modify s/4/44/ stuff &&
|
|
|
|
git commit -a -m "Change 4" &&
|
|
|
|
git push &&
|
|
|
|
|
|
|
|
modify s/44/55/ stuff &&
|
|
|
|
git commit --amend -a -m "Modified Change 4"
|
2010-08-13 01:50:49 +00:00
|
|
|
)
|
|
|
|
'
|
|
|
|
|
pull --rebase: Avoid spurious conflicts and reapplying unnecessary patches
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>
2010-08-13 01:50:50 +00:00
|
|
|
test_expect_success 'git pull --rebase does not reapply old patches' '
|
2019-11-12 23:07:48 +00:00
|
|
|
(
|
|
|
|
cd dst &&
|
|
|
|
test_must_fail git pull --rebase &&
|
2020-02-15 21:36:40 +00:00
|
|
|
cat .git/rebase-merge/done .git/rebase-merge/git-rebase-todo >work &&
|
|
|
|
grep -v -e \# -e ^$ work >patches &&
|
|
|
|
test_line_count = 1 patches &&
|
|
|
|
rm -f work
|
2010-08-13 01:50:49 +00:00
|
|
|
)
|
|
|
|
'
|
|
|
|
|
2010-11-13 22:58:22 +00:00
|
|
|
test_expect_success 'git pull --rebase against local branch' '
|
|
|
|
git checkout -b copy2 to-rebase-orig &&
|
|
|
|
git pull --rebase . to-rebase &&
|
2019-11-12 23:08:12 +00:00
|
|
|
echo "conflicting modification" >expect &&
|
|
|
|
test_cmp expect file &&
|
|
|
|
echo file >expect &&
|
|
|
|
test_cmp expect file2
|
2010-11-13 22:58:22 +00:00
|
|
|
'
|
|
|
|
|
2006-11-16 19:47:22 +00:00
|
|
|
test_done
|