2009-04-05 04:46:58 +04:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='merging with submodules'
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
#
|
|
|
|
# history
|
|
|
|
#
|
|
|
|
# a --- c
|
|
|
|
# / \ /
|
|
|
|
# root X
|
|
|
|
# \ / \
|
|
|
|
# b --- d
|
|
|
|
#
|
|
|
|
|
|
|
|
test_expect_success setup '
|
|
|
|
|
|
|
|
mkdir sub &&
|
|
|
|
(cd sub &&
|
|
|
|
git init &&
|
|
|
|
echo original > file &&
|
|
|
|
git add file &&
|
|
|
|
test_tick &&
|
|
|
|
git commit -m sub-root) &&
|
|
|
|
git add sub &&
|
|
|
|
test_tick &&
|
|
|
|
git commit -m root &&
|
|
|
|
|
|
|
|
git checkout -b a master &&
|
|
|
|
(cd sub &&
|
|
|
|
echo A > file &&
|
|
|
|
git add file &&
|
|
|
|
test_tick &&
|
|
|
|
git commit -m sub-a) &&
|
|
|
|
git add sub &&
|
|
|
|
test_tick &&
|
|
|
|
git commit -m a &&
|
|
|
|
|
|
|
|
git checkout -b b master &&
|
|
|
|
(cd sub &&
|
|
|
|
echo B > file &&
|
|
|
|
git add file &&
|
|
|
|
test_tick &&
|
|
|
|
git commit -m sub-b) &&
|
|
|
|
git add sub &&
|
|
|
|
test_tick &&
|
2010-07-06 23:34:31 +04:00
|
|
|
git commit -m b &&
|
2009-04-05 04:46:58 +04:00
|
|
|
|
|
|
|
git checkout -b c a &&
|
|
|
|
git merge -s ours b &&
|
|
|
|
|
|
|
|
git checkout -b d b &&
|
|
|
|
git merge -s ours a
|
|
|
|
'
|
|
|
|
|
2010-07-07 17:39:13 +04:00
|
|
|
# History setup
|
|
|
|
#
|
submodule: process conflicting submodules only once
During a merge module_list returns conflicting submodules several times
(stage 1,2,3) which caused the submodules to be used multiple times in
git submodule init, sync, update and status command.
There are 5 callers of module_list; they all read (mode, sha1, stage,
path) tuple, and most of them care only about path. As a first level
approximation, it should be Ok (in the sense that it does not make things
worse than it currently is) to filter the duplicate paths from module_list
output, but some callers should change their behaviour when the merge in
the superproject still has conflicts.
Notice the higher-stage entries, and emit only one record from
module_list, but while doing so, mark the entry with "U" (not [0-3]) in
the $stage field and null out the SHA-1 part, as the object name for the
lowest stage does not give any useful information to the caller, and this
way any caller that uses the object name would hopefully barf. Then
update the codepaths for each subcommands this way:
- "update" should not touch the submodule repository, because we do not
know what commit should be checked out yet.
- "status" reports the conflicting submodules as 'U000...000' and does
not recurse into them (we might later want to make it recurse).
- The command called by "foreach" may want to do whatever it wants to do
by noticing the merged status in the superproject itself, so feed the
path to it from module_list as before, but only once per submodule.
- "init" and "sync" are unlikely things to do while the superproject is
still not merged, but as long as a submodule is there in $path, there
is no point skipping it. It might however want to take the merged
status of .gitmodules into account, but that is outside of the scope of
this topic.
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 09:20:02 +04:00
|
|
|
# b
|
|
|
|
# / \
|
|
|
|
# init -- a d
|
|
|
|
# \ \ /
|
|
|
|
# g c
|
2010-07-07 17:39:13 +04:00
|
|
|
#
|
|
|
|
# a in the main repository records to sub-a in the submodule and
|
|
|
|
# analogous b and c. d should be automatically found by merging c into
|
|
|
|
# b in the main repository.
|
|
|
|
test_expect_success 'setup for merge search' '
|
|
|
|
mkdir merge-search &&
|
2010-09-02 01:01:49 +04:00
|
|
|
(cd merge-search &&
|
2010-07-07 17:39:13 +04:00
|
|
|
git init &&
|
|
|
|
mkdir sub &&
|
|
|
|
(cd sub &&
|
|
|
|
git init &&
|
|
|
|
echo "file-a" > file-a &&
|
|
|
|
git add file-a &&
|
|
|
|
git commit -m "sub-a" &&
|
|
|
|
git branch sub-a) &&
|
submodule: process conflicting submodules only once
During a merge module_list returns conflicting submodules several times
(stage 1,2,3) which caused the submodules to be used multiple times in
git submodule init, sync, update and status command.
There are 5 callers of module_list; they all read (mode, sha1, stage,
path) tuple, and most of them care only about path. As a first level
approximation, it should be Ok (in the sense that it does not make things
worse than it currently is) to filter the duplicate paths from module_list
output, but some callers should change their behaviour when the merge in
the superproject still has conflicts.
Notice the higher-stage entries, and emit only one record from
module_list, but while doing so, mark the entry with "U" (not [0-3]) in
the $stage field and null out the SHA-1 part, as the object name for the
lowest stage does not give any useful information to the caller, and this
way any caller that uses the object name would hopefully barf. Then
update the codepaths for each subcommands this way:
- "update" should not touch the submodule repository, because we do not
know what commit should be checked out yet.
- "status" reports the conflicting submodules as 'U000...000' and does
not recurse into them (we might later want to make it recurse).
- The command called by "foreach" may want to do whatever it wants to do
by noticing the merged status in the superproject itself, so feed the
path to it from module_list as before, but only once per submodule.
- "init" and "sync" are unlikely things to do while the superproject is
still not merged, but as long as a submodule is there in $path, there
is no point skipping it. It might however want to take the merged
status of .gitmodules into account, but that is outside of the scope of
this topic.
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 09:20:02 +04:00
|
|
|
git commit --allow-empty -m init &&
|
|
|
|
git branch init &&
|
2010-07-07 17:39:13 +04:00
|
|
|
git add sub &&
|
|
|
|
git commit -m "a" &&
|
|
|
|
git branch a &&
|
|
|
|
|
|
|
|
git checkout -b b &&
|
|
|
|
(cd sub &&
|
|
|
|
git checkout -b sub-b &&
|
|
|
|
echo "file-b" > file-b &&
|
|
|
|
git add file-b &&
|
|
|
|
git commit -m "sub-b") &&
|
|
|
|
git commit -a -m "b" &&
|
|
|
|
|
|
|
|
git checkout -b c a &&
|
|
|
|
(cd sub &&
|
|
|
|
git checkout -b sub-c sub-a &&
|
|
|
|
echo "file-c" > file-c &&
|
|
|
|
git add file-c &&
|
|
|
|
git commit -m "sub-c") &&
|
|
|
|
git commit -a -m "c" &&
|
|
|
|
|
|
|
|
git checkout -b d a &&
|
|
|
|
(cd sub &&
|
|
|
|
git checkout -b sub-d sub-b &&
|
|
|
|
git merge sub-c) &&
|
|
|
|
git commit -a -m "d" &&
|
submodule: process conflicting submodules only once
During a merge module_list returns conflicting submodules several times
(stage 1,2,3) which caused the submodules to be used multiple times in
git submodule init, sync, update and status command.
There are 5 callers of module_list; they all read (mode, sha1, stage,
path) tuple, and most of them care only about path. As a first level
approximation, it should be Ok (in the sense that it does not make things
worse than it currently is) to filter the duplicate paths from module_list
output, but some callers should change their behaviour when the merge in
the superproject still has conflicts.
Notice the higher-stage entries, and emit only one record from
module_list, but while doing so, mark the entry with "U" (not [0-3]) in
the $stage field and null out the SHA-1 part, as the object name for the
lowest stage does not give any useful information to the caller, and this
way any caller that uses the object name would hopefully barf. Then
update the codepaths for each subcommands this way:
- "update" should not touch the submodule repository, because we do not
know what commit should be checked out yet.
- "status" reports the conflicting submodules as 'U000...000' and does
not recurse into them (we might later want to make it recurse).
- The command called by "foreach" may want to do whatever it wants to do
by noticing the merged status in the superproject itself, so feed the
path to it from module_list as before, but only once per submodule.
- "init" and "sync" are unlikely things to do while the superproject is
still not merged, but as long as a submodule is there in $path, there
is no point skipping it. It might however want to take the merged
status of .gitmodules into account, but that is outside of the scope of
this topic.
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 09:20:02 +04:00
|
|
|
git branch test b &&
|
|
|
|
|
|
|
|
git checkout -b g init &&
|
|
|
|
(cd sub &&
|
|
|
|
git checkout -b sub-g sub-c) &&
|
|
|
|
git add sub &&
|
|
|
|
git commit -a -m "g")
|
2010-07-07 17:39:13 +04:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'merge with one side as a fast-forward of the other' '
|
|
|
|
(cd merge-search &&
|
|
|
|
git checkout -b test-forward b &&
|
|
|
|
git merge d &&
|
|
|
|
git ls-tree test-forward sub | cut -f1 | cut -f3 -d" " > actual &&
|
|
|
|
(cd sub &&
|
|
|
|
git rev-parse sub-d > ../expect) &&
|
|
|
|
test_cmp actual expect)
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'merging should conflict for non fast-forward' '
|
|
|
|
(cd merge-search &&
|
|
|
|
git checkout -b test-nonforward b &&
|
|
|
|
(cd sub &&
|
|
|
|
git rev-parse sub-d > ../expect) &&
|
|
|
|
test_must_fail git merge c 2> actual &&
|
|
|
|
grep $(cat expect) actual > /dev/null &&
|
|
|
|
git reset --hard)
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'merging should fail for ambiguous common parent' '
|
2010-09-02 01:01:49 +04:00
|
|
|
(cd merge-search &&
|
2010-07-07 17:39:13 +04:00
|
|
|
git checkout -b test-ambiguous b &&
|
|
|
|
(cd sub &&
|
|
|
|
git checkout -b ambiguous sub-b &&
|
|
|
|
git merge sub-c &&
|
|
|
|
git rev-parse sub-d > ../expect1 &&
|
|
|
|
git rev-parse ambiguous > ../expect2) &&
|
|
|
|
test_must_fail git merge c 2> actual &&
|
|
|
|
grep $(cat expect1) actual > /dev/null &&
|
|
|
|
grep $(cat expect2) actual > /dev/null &&
|
2010-09-02 01:01:49 +04:00
|
|
|
git reset --hard)
|
2010-07-07 17:39:13 +04:00
|
|
|
'
|
|
|
|
|
|
|
|
# in a situation like this
|
|
|
|
#
|
|
|
|
# submodule tree:
|
|
|
|
#
|
|
|
|
# sub-a --- sub-b --- sub-d
|
|
|
|
#
|
|
|
|
# main tree:
|
|
|
|
#
|
|
|
|
# e (sub-a)
|
|
|
|
# /
|
|
|
|
# bb (sub-b)
|
|
|
|
# \
|
|
|
|
# f (sub-d)
|
|
|
|
#
|
|
|
|
# A merge between e and f should fail because one of the submodule
|
|
|
|
# commits (sub-a) does not descend from the submodule merge-base (sub-b).
|
|
|
|
#
|
|
|
|
test_expect_success 'merging should fail for changes that are backwards' '
|
2010-09-02 01:01:49 +04:00
|
|
|
(cd merge-search &&
|
2010-07-07 17:39:13 +04:00
|
|
|
git checkout -b bb a &&
|
|
|
|
(cd sub &&
|
|
|
|
git checkout sub-b) &&
|
|
|
|
git commit -a -m "bb" &&
|
|
|
|
|
|
|
|
git checkout -b e bb &&
|
|
|
|
(cd sub &&
|
|
|
|
git checkout sub-a) &&
|
|
|
|
git commit -a -m "e" &&
|
|
|
|
|
|
|
|
git checkout -b f bb &&
|
|
|
|
(cd sub &&
|
|
|
|
git checkout sub-d) &&
|
|
|
|
git commit -a -m "f" &&
|
2009-04-05 04:46:58 +04:00
|
|
|
|
2010-07-07 17:39:13 +04:00
|
|
|
git checkout -b test-backward e &&
|
2010-09-02 01:01:49 +04:00
|
|
|
test_must_fail git merge f)
|
2009-04-05 04:46:58 +04:00
|
|
|
'
|
|
|
|
|
submodule: process conflicting submodules only once
During a merge module_list returns conflicting submodules several times
(stage 1,2,3) which caused the submodules to be used multiple times in
git submodule init, sync, update and status command.
There are 5 callers of module_list; they all read (mode, sha1, stage,
path) tuple, and most of them care only about path. As a first level
approximation, it should be Ok (in the sense that it does not make things
worse than it currently is) to filter the duplicate paths from module_list
output, but some callers should change their behaviour when the merge in
the superproject still has conflicts.
Notice the higher-stage entries, and emit only one record from
module_list, but while doing so, mark the entry with "U" (not [0-3]) in
the $stage field and null out the SHA-1 part, as the object name for the
lowest stage does not give any useful information to the caller, and this
way any caller that uses the object name would hopefully barf. Then
update the codepaths for each subcommands this way:
- "update" should not touch the submodule repository, because we do not
know what commit should be checked out yet.
- "status" reports the conflicting submodules as 'U000...000' and does
not recurse into them (we might later want to make it recurse).
- The command called by "foreach" may want to do whatever it wants to do
by noticing the merged status in the superproject itself, so feed the
path to it from module_list as before, but only once per submodule.
- "init" and "sync" are unlikely things to do while the superproject is
still not merged, but as long as a submodule is there in $path, there
is no point skipping it. It might however want to take the merged
status of .gitmodules into account, but that is outside of the scope of
this topic.
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Thanks-to: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-30 09:20:02 +04:00
|
|
|
|
|
|
|
# Check that the conflicting submodule is detected when it is
|
|
|
|
# in the common ancestor. status should be 'U00...00"
|
|
|
|
test_expect_success 'git submodule status should display the merge conflict properly with merge base' '
|
|
|
|
(cd merge-search &&
|
|
|
|
cat >.gitmodules <<EOF &&
|
|
|
|
[submodule "sub"]
|
|
|
|
path = sub
|
|
|
|
url = $TRASH_DIRECTORY/sub
|
|
|
|
EOF
|
|
|
|
cat >expect <<EOF &&
|
|
|
|
U0000000000000000000000000000000000000000 sub
|
|
|
|
EOF
|
|
|
|
git submodule status > actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
git reset --hard)
|
|
|
|
'
|
|
|
|
|
|
|
|
# Check that the conflicting submodule is detected when it is
|
|
|
|
# not in the common ancestor. status should be 'U00...00"
|
|
|
|
test_expect_success 'git submodule status should display the merge conflict properly without merge-base' '
|
|
|
|
(cd merge-search &&
|
|
|
|
git checkout -b test-no-merge-base g &&
|
|
|
|
test_must_fail git merge b &&
|
|
|
|
cat >.gitmodules <<EOF &&
|
|
|
|
[submodule "sub"]
|
|
|
|
path = sub
|
|
|
|
url = $TRASH_DIRECTORY/sub
|
|
|
|
EOF
|
|
|
|
cat >expect <<EOF &&
|
|
|
|
U0000000000000000000000000000000000000000 sub
|
|
|
|
EOF
|
|
|
|
git submodule status > actual &&
|
|
|
|
test_cmp expect actual &&
|
|
|
|
git reset --hard)
|
|
|
|
'
|
|
|
|
|
|
|
|
|
2009-04-05 04:46:59 +04:00
|
|
|
test_expect_success 'merging with a modify/modify conflict between merge bases' '
|
2009-04-05 04:46:58 +04:00
|
|
|
git reset --hard HEAD &&
|
|
|
|
git checkout -b test2 c &&
|
|
|
|
git merge d
|
|
|
|
'
|
|
|
|
|
2011-10-13 16:59:04 +04:00
|
|
|
# canonical criss-cross history in top and submodule
|
|
|
|
test_expect_success 'setup for recursive merge with submodule' '
|
|
|
|
mkdir merge-recursive &&
|
|
|
|
(cd merge-recursive &&
|
|
|
|
git init &&
|
|
|
|
mkdir sub &&
|
|
|
|
(cd sub &&
|
|
|
|
git init &&
|
|
|
|
test_commit a &&
|
|
|
|
git checkout -b sub-b master &&
|
|
|
|
test_commit b &&
|
|
|
|
git checkout -b sub-c master &&
|
|
|
|
test_commit c &&
|
|
|
|
git checkout -b sub-bc sub-b &&
|
|
|
|
git merge sub-c &&
|
|
|
|
git checkout -b sub-cb sub-c &&
|
|
|
|
git merge sub-b &&
|
|
|
|
git checkout master) &&
|
|
|
|
git add sub &&
|
|
|
|
git commit -m a &&
|
|
|
|
git checkout -b top-b master &&
|
|
|
|
(cd sub && git checkout sub-b) &&
|
|
|
|
git add sub &&
|
|
|
|
git commit -m b &&
|
|
|
|
git checkout -b top-c master &&
|
|
|
|
(cd sub && git checkout sub-c) &&
|
|
|
|
git add sub &&
|
|
|
|
git commit -m c &&
|
|
|
|
git checkout -b top-bc top-b &&
|
|
|
|
git merge -s ours --no-commit top-c &&
|
|
|
|
(cd sub && git checkout sub-bc) &&
|
|
|
|
git add sub &&
|
|
|
|
git commit -m bc &&
|
|
|
|
git checkout -b top-cb top-c &&
|
|
|
|
git merge -s ours --no-commit top-b &&
|
|
|
|
(cd sub && git checkout sub-cb) &&
|
|
|
|
git add sub &&
|
|
|
|
git commit -m cb)
|
|
|
|
'
|
|
|
|
|
|
|
|
# merge should leave submodule unmerged in index
|
2011-10-13 16:59:05 +04:00
|
|
|
test_expect_success 'recursive merge with submodule' '
|
2011-10-13 16:59:04 +04:00
|
|
|
(cd merge-recursive &&
|
|
|
|
test_must_fail git merge top-bc &&
|
|
|
|
echo "160000 $(git rev-parse top-cb:sub) 2 sub" > expect2 &&
|
|
|
|
echo "160000 $(git rev-parse top-bc:sub) 3 sub" > expect3 &&
|
|
|
|
git ls-files -u > actual &&
|
|
|
|
grep "$(cat expect2)" actual > /dev/null &&
|
|
|
|
grep "$(cat expect3)" actual > /dev/null)
|
|
|
|
'
|
|
|
|
|
2009-04-05 04:46:58 +04:00
|
|
|
test_done
|