git-commit-vandalism/t/t5520-pull.sh

377 lines
9.8 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='pulling into void'
. ./test-lib.sh
modify () {
sed -e "$1" <"$2" >"$2.x" &&
mv "$2.x" "$2"
}
D=`pwd`
test_expect_success setup '
echo file >file &&
git add file &&
git commit -a -m original
'
test_expect_success 'pulling into void' '
mkdir cloned &&
cd cloned &&
git init &&
git pull ..
'
cd "$D"
test_expect_success 'checking the results' '
test -f file &&
test -f cloned/file &&
test_cmp file cloned/file
'
test_expect_success 'pulling into void using master:master' '
mkdir cloned-uho &&
(
cd cloned-uho &&
git init &&
git pull .. master:master
) &&
test -f file &&
test -f cloned-uho/file &&
test_cmp file cloned-uho/file
'
test_expect_success 'pulling into void does not overwrite untracked files' '
git init cloned-untracked &&
(
cd cloned-untracked &&
echo untracked >file &&
test_must_fail git pull .. master &&
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-21 00:38:28 +02: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 &&
test_must_fail git pull .. master &&
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 &&
git pull .. master &&
echo "new tracked file" >expect &&
test_cmp expect newfile &&
git cat-file blob :newfile >newfile.index &&
test_cmp expect newfile.index
)
'
test_expect_success 'test . as a remote' '
git branch copy master &&
git config branch.copy.remote . &&
git config branch.copy.merge refs/heads/master &&
echo updated >file &&
git commit -a -m updated &&
git checkout copy &&
test `cat file` = file &&
git pull &&
test `cat file` = updated
'
test_expect_success 'the default remote . should not break explicit pull' '
git checkout -b second master^ &&
echo modified >file &&
git commit -a -m modified &&
git checkout copy &&
git reset --hard HEAD^ &&
test `cat file` = file &&
git pull . second &&
test `cat file` = modified
'
test_expect_success '--rebase' '
git branch to-rebase &&
echo modified again > file &&
git commit -m file file &&
git checkout to-rebase &&
echo new > file2 &&
git add file2 &&
git commit -m "new file" &&
git tag before-rebase &&
git pull --rebase . copy &&
test $(git rev-parse HEAD^) = $(git rev-parse copy) &&
test new = $(git show HEAD:file2)
'
test_expect_success 'pull.rebase' '
git reset --hard before-rebase &&
test_config pull.rebase true &&
git pull . copy &&
test $(git rev-parse HEAD^) = $(git rev-parse copy) &&
test new = $(git show HEAD:file2)
'
test_expect_success 'branch.to-rebase.rebase' '
git reset --hard before-rebase &&
test_config branch.to-rebase.rebase true &&
git pull . copy &&
test $(git rev-parse HEAD^) = $(git rev-parse copy) &&
test new = $(git show HEAD:file2)
'
test_expect_success 'branch.to-rebase.rebase should override pull.rebase' '
git reset --hard before-rebase &&
test_config pull.rebase true &&
test_config branch.to-rebase.rebase false &&
git pull . copy &&
test $(git rev-parse HEAD^) != $(git rev-parse copy) &&
test new = $(git show HEAD:file2)
'
# add a feature branch, keep-merge, that is merged into master, so the
# 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 &&
test $(git rev-parse HEAD^1) = $(git rev-parse before-preserve-rebase) &&
test $(git rev-parse HEAD^2) = $(git rev-parse copy) &&
test file3 = $(git show HEAD:file3.t)
'
test_expect_success 'pull.rebase=true flattens keep-merge' '
git reset --hard before-preserve-rebase &&
test_config pull.rebase true &&
git pull . copy &&
test $(git rev-parse HEAD^^) = $(git rev-parse copy) &&
test file3 = $(git show HEAD:file3.t)
'
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 &&
test $(git rev-parse HEAD^^) = $(git rev-parse copy) &&
test file3 = $(git show HEAD:file3.t)
'
test_expect_success 'pull.rebase=preserve rebases and merges keep-merge' '
git reset --hard before-preserve-rebase &&
test_config pull.rebase preserve &&
git pull . copy &&
test $(git rev-parse HEAD^^) = $(git rev-parse copy) &&
test $(git rev-parse HEAD^2) = $(git rev-parse keep-merge)
'
test_expect_success 'pull.rebase=invalid fails' '
git reset --hard before-preserve-rebase &&
test_config pull.rebase invalid &&
! git pull . copy
'
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 &&
test $(git rev-parse HEAD^1) = $(git rev-parse before-preserve-rebase) &&
test $(git rev-parse HEAD^2) = $(git rev-parse copy) &&
test file3 = $(git show HEAD:file3.t)
'
test_expect_success '--rebase=true rebases and flattens keep-merge' '
git reset --hard before-preserve-rebase &&
test_config pull.rebase preserve &&
git pull --rebase=true . copy &&
test $(git rev-parse HEAD^^) = $(git rev-parse copy) &&
test file3 = $(git show HEAD:file3.t)
'
test_expect_success '--rebase=preserve rebases and merges keep-merge' '
git reset --hard before-preserve-rebase &&
test_config pull.rebase true &&
git pull --rebase=preserve . copy &&
test $(git rev-parse HEAD^^) = $(git rev-parse copy) &&
test $(git rev-parse HEAD^2) = $(git rev-parse keep-merge)
'
test_expect_success '--rebase=invalid fails' '
git reset --hard before-preserve-rebase &&
! git pull --rebase=invalid . copy
'
test_expect_success '--rebase overrides pull.rebase=preserve and flattens keep-merge' '
git reset --hard before-preserve-rebase &&
test_config pull.rebase preserve &&
git pull --rebase . copy &&
test $(git rev-parse HEAD^^) = $(git rev-parse copy) &&
test file3 = $(git show HEAD:file3.t)
'
test_expect_success '--rebase with rebased upstream' '
git remote add -f me . &&
git checkout copy &&
git tag copy-orig &&
git reset --hard HEAD^ &&
echo conflicting modification > file &&
git commit -m conflict file &&
git checkout to-rebase &&
echo file > file2 &&
git commit -m to-rebase file2 &&
git tag to-rebase-orig &&
git pull --rebase me copy &&
test "conflicting modification" = "$(cat file)" &&
test file = $(cat file2)
'
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 &&
test "conflicting modification" = "$(cat file)" &&
test file = $(cat file2)
'
test_expect_success 'rebased upstream + fetch + pull --rebase' '
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 &&
git pull --rebase &&
test "conflicting modification" = "$(cat file)" &&
test file = "$(cat file2)"
'
test_expect_success 'pull --rebase dies early with dirty working directory' '
git checkout to-rebase &&
git update-ref refs/remotes/me/copy copy^ &&
COPY=$(git rev-parse --verify me/copy) &&
git rebase --onto $COPY copy &&
test_config branch.to-rebase.remote me &&
test_config branch.to-rebase.merge refs/heads/copy &&
test_config branch.to-rebase.rebase true &&
echo dirty >> file &&
git add file &&
test_must_fail git pull &&
test $COPY = $(git rev-parse --verify me/copy) &&
git checkout HEAD -- file &&
git pull &&
test $COPY != $(git rev-parse --verify me/copy)
'
test_expect_success 'pull --rebase works on branch yet to be born' '
git rev-parse master >expect &&
mkdir empty_repo &&
(cd empty_repo &&
git init &&
git pull --rebase .. master &&
git rev-parse HEAD >../actual
) &&
test_cmp expect actual
'
test_expect_success 'setup for detecting upstreamed changes' '
mkdir src &&
(cd src &&
git init &&
printf "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n" > stuff &&
git add stuff &&
git commit -m "Initial revision"
) &&
git clone src dst &&
(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"
) &&
(cd dst &&
modify s/5/43/ stuff &&
git commit -a -m "Independent discovery of 5->43"
)
'
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 03:50:50 +02:00
test_expect_success 'git pull --rebase detects upstreamed changes' '
(cd dst &&
git pull --rebase &&
test -z "$(git ls-files -u)"
)
'
test_expect_success 'setup for avoiding reapplying old patches' '
(cd dst &&
test_might_fail git rebase --abort &&
git reset --hard origin/master
) &&
git clone --bare src src-replace.git &&
rm -rf src &&
mv src-replace.git src &&
(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"
)
'
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 03:50:50 +02:00
test_expect_success 'git pull --rebase does not reapply old patches' '
(cd dst &&
test_must_fail git pull --rebase &&
test 1 = $(find .git/rebase-apply -name "000*" | wc -l)
)
'
test_expect_success 'git pull --rebase against local branch' '
git checkout -b copy2 to-rebase-orig &&
git pull --rebase . to-rebase &&
test "conflicting modification" = "$(cat file)" &&
test file = "$(cat file2)"
'
test_done