git/t/t6437-submodule-merge.sh

547 строки
14 KiB
Bash
Исходник Постоянная ссылка Обычный вид История

#!/bin/sh
test_description='merging with submodules'
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-19 02:44:19 +03:00
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
GIT_TEST_FATAL_REGISTER_SUBMODULE_ODB=1
export GIT_TEST_FATAL_REGISTER_SUBMODULE_ODB
TEST_PASSES_SANITIZE_LEAK=true
. ./test-lib.sh
. "$TEST_DIRECTORY"/lib-merge.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 main &&
(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 main &&
(cd sub &&
echo B > file &&
git add file &&
test_tick &&
git commit -m sub-b) &&
git add sub &&
test_tick &&
git commit -m b &&
git checkout -b c a &&
git merge -s ours b &&
git checkout -b d b &&
git merge -s ours a
'
# 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
#
# 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 &&
(cd merge-search &&
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 &&
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") &&
submodule merge: update conflict error message When attempting to merge in a superproject with conflicting submodule pointers that cannot be fast-forwarded or trivially resolved, the merge fails and Git prints an error message that accurately describes the failure, but does not provide steps for the user to resolve the error. Git is left in a conflicted state, which requires the user to: 1. merge submodules or update submodules to an already existing commit that reflects the merge 2. add submodules changes to the superproject 3. finish merging superproject These steps are non-obvious for newer submodule users to figure out based on the error message and neither `git submodule status` nor `git status` provide any useful pointers. Update error message to provide steps to resolve submodule merge conflict. Future work could involve adding an advice flag to the message. Although the message is long, it also has the id of the submodule commit that needs to be merged, which could be useful information for the user. Additionally, 5 merge failures that resulted in an early return have been updated to reflect the status of the merge. 1. Null merge base (null o): CONFLICT_SUBMODULE_NULL_MERGE_BASE added as a new conflict type and will print updated error message. 2. Null merge side a (null a): BUG(). See [1] for discussion 3. Null merge side b (null b): BUG(). See [1] for discussion 4. Submodule not checked out: added NEEDSWORK bit 5. Submodule commits not present: added NEEDSWORK bit The errors with a NEEDSWORK bit deserve a more detailed explanation of how to resolve them. See [2] for more context. [1] https://lore.kernel.org/git/CABPp-BE0qGwUy80dmVszkJQ+tcpfLRW0OZyErymzhZ9+HWY1mw@mail.gmail.com/ [2] https://lore.kernel.org/git/xmqqpmhjjwo9.fsf@gitster.g/ Signed-off-by: Calvin Wan <calvinwan@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-04 22:51:05 +03:00
git commit -a -m "c")
'
submodule merge: update conflict error message When attempting to merge in a superproject with conflicting submodule pointers that cannot be fast-forwarded or trivially resolved, the merge fails and Git prints an error message that accurately describes the failure, but does not provide steps for the user to resolve the error. Git is left in a conflicted state, which requires the user to: 1. merge submodules or update submodules to an already existing commit that reflects the merge 2. add submodules changes to the superproject 3. finish merging superproject These steps are non-obvious for newer submodule users to figure out based on the error message and neither `git submodule status` nor `git status` provide any useful pointers. Update error message to provide steps to resolve submodule merge conflict. Future work could involve adding an advice flag to the message. Although the message is long, it also has the id of the submodule commit that needs to be merged, which could be useful information for the user. Additionally, 5 merge failures that resulted in an early return have been updated to reflect the status of the merge. 1. Null merge base (null o): CONFLICT_SUBMODULE_NULL_MERGE_BASE added as a new conflict type and will print updated error message. 2. Null merge side a (null a): BUG(). See [1] for discussion 3. Null merge side b (null b): BUG(). See [1] for discussion 4. Submodule not checked out: added NEEDSWORK bit 5. Submodule commits not present: added NEEDSWORK bit The errors with a NEEDSWORK bit deserve a more detailed explanation of how to resolve them. See [2] for more context. [1] https://lore.kernel.org/git/CABPp-BE0qGwUy80dmVszkJQ+tcpfLRW0OZyErymzhZ9+HWY1mw@mail.gmail.com/ [2] https://lore.kernel.org/git/xmqqpmhjjwo9.fsf@gitster.g/ Signed-off-by: Calvin Wan <calvinwan@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-04 22:51:05 +03:00
test_expect_success 'merging should conflict for non fast-forward' '
test_when_finished "git -C merge-search reset --hard" &&
(cd merge-search &&
git checkout -b test-nonforward-a b &&
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
then
test_must_fail git merge c 2>actual &&
submodule merge: update conflict error message When attempting to merge in a superproject with conflicting submodule pointers that cannot be fast-forwarded or trivially resolved, the merge fails and Git prints an error message that accurately describes the failure, but does not provide steps for the user to resolve the error. Git is left in a conflicted state, which requires the user to: 1. merge submodules or update submodules to an already existing commit that reflects the merge 2. add submodules changes to the superproject 3. finish merging superproject These steps are non-obvious for newer submodule users to figure out based on the error message and neither `git submodule status` nor `git status` provide any useful pointers. Update error message to provide steps to resolve submodule merge conflict. Future work could involve adding an advice flag to the message. Although the message is long, it also has the id of the submodule commit that needs to be merged, which could be useful information for the user. Additionally, 5 merge failures that resulted in an early return have been updated to reflect the status of the merge. 1. Null merge base (null o): CONFLICT_SUBMODULE_NULL_MERGE_BASE added as a new conflict type and will print updated error message. 2. Null merge side a (null a): BUG(). See [1] for discussion 3. Null merge side b (null b): BUG(). See [1] for discussion 4. Submodule not checked out: added NEEDSWORK bit 5. Submodule commits not present: added NEEDSWORK bit The errors with a NEEDSWORK bit deserve a more detailed explanation of how to resolve them. See [2] for more context. [1] https://lore.kernel.org/git/CABPp-BE0qGwUy80dmVszkJQ+tcpfLRW0OZyErymzhZ9+HWY1mw@mail.gmail.com/ [2] https://lore.kernel.org/git/xmqqpmhjjwo9.fsf@gitster.g/ Signed-off-by: Calvin Wan <calvinwan@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-04 22:51:05 +03:00
sub_expect="go to submodule (sub), and either merge commit $(git -C sub rev-parse --short sub-c)" &&
grep "$sub_expect" actual
else
test_must_fail git merge c 2> actual
fi)
'
test_expect_success 'finish setup for merge-search' '
(cd merge-search &&
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")
'
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 expect actual)
'
submodule merge: update conflict error message When attempting to merge in a superproject with conflicting submodule pointers that cannot be fast-forwarded or trivially resolved, the merge fails and Git prints an error message that accurately describes the failure, but does not provide steps for the user to resolve the error. Git is left in a conflicted state, which requires the user to: 1. merge submodules or update submodules to an already existing commit that reflects the merge 2. add submodules changes to the superproject 3. finish merging superproject These steps are non-obvious for newer submodule users to figure out based on the error message and neither `git submodule status` nor `git status` provide any useful pointers. Update error message to provide steps to resolve submodule merge conflict. Future work could involve adding an advice flag to the message. Although the message is long, it also has the id of the submodule commit that needs to be merged, which could be useful information for the user. Additionally, 5 merge failures that resulted in an early return have been updated to reflect the status of the merge. 1. Null merge base (null o): CONFLICT_SUBMODULE_NULL_MERGE_BASE added as a new conflict type and will print updated error message. 2. Null merge side a (null a): BUG(). See [1] for discussion 3. Null merge side b (null b): BUG(). See [1] for discussion 4. Submodule not checked out: added NEEDSWORK bit 5. Submodule commits not present: added NEEDSWORK bit The errors with a NEEDSWORK bit deserve a more detailed explanation of how to resolve them. See [2] for more context. [1] https://lore.kernel.org/git/CABPp-BE0qGwUy80dmVszkJQ+tcpfLRW0OZyErymzhZ9+HWY1mw@mail.gmail.com/ [2] https://lore.kernel.org/git/xmqqpmhjjwo9.fsf@gitster.g/ Signed-off-by: Calvin Wan <calvinwan@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-04 22:51:05 +03:00
test_expect_success 'merging should conflict for non fast-forward (resolution exists)' '
(cd merge-search &&
submodule merge: update conflict error message When attempting to merge in a superproject with conflicting submodule pointers that cannot be fast-forwarded or trivially resolved, the merge fails and Git prints an error message that accurately describes the failure, but does not provide steps for the user to resolve the error. Git is left in a conflicted state, which requires the user to: 1. merge submodules or update submodules to an already existing commit that reflects the merge 2. add submodules changes to the superproject 3. finish merging superproject These steps are non-obvious for newer submodule users to figure out based on the error message and neither `git submodule status` nor `git status` provide any useful pointers. Update error message to provide steps to resolve submodule merge conflict. Future work could involve adding an advice flag to the message. Although the message is long, it also has the id of the submodule commit that needs to be merged, which could be useful information for the user. Additionally, 5 merge failures that resulted in an early return have been updated to reflect the status of the merge. 1. Null merge base (null o): CONFLICT_SUBMODULE_NULL_MERGE_BASE added as a new conflict type and will print updated error message. 2. Null merge side a (null a): BUG(). See [1] for discussion 3. Null merge side b (null b): BUG(). See [1] for discussion 4. Submodule not checked out: added NEEDSWORK bit 5. Submodule commits not present: added NEEDSWORK bit The errors with a NEEDSWORK bit deserve a more detailed explanation of how to resolve them. See [2] for more context. [1] https://lore.kernel.org/git/CABPp-BE0qGwUy80dmVszkJQ+tcpfLRW0OZyErymzhZ9+HWY1mw@mail.gmail.com/ [2] https://lore.kernel.org/git/xmqqpmhjjwo9.fsf@gitster.g/ Signed-off-by: Calvin Wan <calvinwan@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-04 22:51:05 +03:00
git checkout -b test-nonforward-b b &&
(cd sub &&
git rev-parse --short sub-d > ../expect) &&
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
then
test_must_fail git merge c >actual 2>sub-actual &&
submodule merge: update conflict error message When attempting to merge in a superproject with conflicting submodule pointers that cannot be fast-forwarded or trivially resolved, the merge fails and Git prints an error message that accurately describes the failure, but does not provide steps for the user to resolve the error. Git is left in a conflicted state, which requires the user to: 1. merge submodules or update submodules to an already existing commit that reflects the merge 2. add submodules changes to the superproject 3. finish merging superproject These steps are non-obvious for newer submodule users to figure out based on the error message and neither `git submodule status` nor `git status` provide any useful pointers. Update error message to provide steps to resolve submodule merge conflict. Future work could involve adding an advice flag to the message. Although the message is long, it also has the id of the submodule commit that needs to be merged, which could be useful information for the user. Additionally, 5 merge failures that resulted in an early return have been updated to reflect the status of the merge. 1. Null merge base (null o): CONFLICT_SUBMODULE_NULL_MERGE_BASE added as a new conflict type and will print updated error message. 2. Null merge side a (null a): BUG(). See [1] for discussion 3. Null merge side b (null b): BUG(). See [1] for discussion 4. Submodule not checked out: added NEEDSWORK bit 5. Submodule commits not present: added NEEDSWORK bit The errors with a NEEDSWORK bit deserve a more detailed explanation of how to resolve them. See [2] for more context. [1] https://lore.kernel.org/git/CABPp-BE0qGwUy80dmVszkJQ+tcpfLRW0OZyErymzhZ9+HWY1mw@mail.gmail.com/ [2] https://lore.kernel.org/git/xmqqpmhjjwo9.fsf@gitster.g/ Signed-off-by: Calvin Wan <calvinwan@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-04 22:51:05 +03:00
sub_expect="go to submodule (sub), and either merge commit $(git -C sub rev-parse --short sub-c)" &&
grep "$sub_expect" sub-actual
else
test_must_fail git merge c 2> actual
fi &&
grep $(cat expect) actual > /dev/null &&
git reset --hard)
'
test_expect_success 'merging should fail for ambiguous common parent' '
(cd merge-search &&
git checkout -b test-ambiguous b &&
(cd sub &&
git checkout -b ambiguous sub-b &&
git merge sub-c &&
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
then
git rev-parse --short sub-d >../expect1 &&
git rev-parse --short ambiguous >../expect2
else
git rev-parse sub-d > ../expect1 &&
git rev-parse ambiguous > ../expect2
fi
) &&
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
then
test_must_fail git merge c >actual 2>sub-actual &&
submodule merge: update conflict error message When attempting to merge in a superproject with conflicting submodule pointers that cannot be fast-forwarded or trivially resolved, the merge fails and Git prints an error message that accurately describes the failure, but does not provide steps for the user to resolve the error. Git is left in a conflicted state, which requires the user to: 1. merge submodules or update submodules to an already existing commit that reflects the merge 2. add submodules changes to the superproject 3. finish merging superproject These steps are non-obvious for newer submodule users to figure out based on the error message and neither `git submodule status` nor `git status` provide any useful pointers. Update error message to provide steps to resolve submodule merge conflict. Future work could involve adding an advice flag to the message. Although the message is long, it also has the id of the submodule commit that needs to be merged, which could be useful information for the user. Additionally, 5 merge failures that resulted in an early return have been updated to reflect the status of the merge. 1. Null merge base (null o): CONFLICT_SUBMODULE_NULL_MERGE_BASE added as a new conflict type and will print updated error message. 2. Null merge side a (null a): BUG(). See [1] for discussion 3. Null merge side b (null b): BUG(). See [1] for discussion 4. Submodule not checked out: added NEEDSWORK bit 5. Submodule commits not present: added NEEDSWORK bit The errors with a NEEDSWORK bit deserve a more detailed explanation of how to resolve them. See [2] for more context. [1] https://lore.kernel.org/git/CABPp-BE0qGwUy80dmVszkJQ+tcpfLRW0OZyErymzhZ9+HWY1mw@mail.gmail.com/ [2] https://lore.kernel.org/git/xmqqpmhjjwo9.fsf@gitster.g/ Signed-off-by: Calvin Wan <calvinwan@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-04 22:51:05 +03:00
sub_expect="go to submodule (sub), and either merge commit $(git -C sub rev-parse --short sub-c)" &&
grep "$sub_expect" sub-actual
else
test_must_fail git merge c 2> actual
fi &&
grep $(cat expect1) actual > /dev/null &&
grep $(cat expect2) actual > /dev/null &&
git reset --hard)
'
# 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' '
(cd merge-search &&
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" &&
git checkout -b test-backward e &&
test_must_fail git merge f 2>actual &&
submodule merge: update conflict error message When attempting to merge in a superproject with conflicting submodule pointers that cannot be fast-forwarded or trivially resolved, the merge fails and Git prints an error message that accurately describes the failure, but does not provide steps for the user to resolve the error. Git is left in a conflicted state, which requires the user to: 1. merge submodules or update submodules to an already existing commit that reflects the merge 2. add submodules changes to the superproject 3. finish merging superproject These steps are non-obvious for newer submodule users to figure out based on the error message and neither `git submodule status` nor `git status` provide any useful pointers. Update error message to provide steps to resolve submodule merge conflict. Future work could involve adding an advice flag to the message. Although the message is long, it also has the id of the submodule commit that needs to be merged, which could be useful information for the user. Additionally, 5 merge failures that resulted in an early return have been updated to reflect the status of the merge. 1. Null merge base (null o): CONFLICT_SUBMODULE_NULL_MERGE_BASE added as a new conflict type and will print updated error message. 2. Null merge side a (null a): BUG(). See [1] for discussion 3. Null merge side b (null b): BUG(). See [1] for discussion 4. Submodule not checked out: added NEEDSWORK bit 5. Submodule commits not present: added NEEDSWORK bit The errors with a NEEDSWORK bit deserve a more detailed explanation of how to resolve them. See [2] for more context. [1] https://lore.kernel.org/git/CABPp-BE0qGwUy80dmVszkJQ+tcpfLRW0OZyErymzhZ9+HWY1mw@mail.gmail.com/ [2] https://lore.kernel.org/git/xmqqpmhjjwo9.fsf@gitster.g/ Signed-off-by: Calvin Wan <calvinwan@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-04 22:51:05 +03:00
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
then
sub_expect="go to submodule (sub), and either merge commit $(git -C sub rev-parse --short sub-d)" &&
grep "$sub_expect" actual
fi)
'
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 &&
U$ZERO_OID sub
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
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 &&
U$ZERO_OID sub
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
EOF
git submodule status > actual &&
test_cmp expect actual &&
git reset --hard)
'
test_expect_success 'merging with a modify/modify conflict between merge bases' '
git reset --hard HEAD &&
git checkout -b test2 c &&
git merge d
'
# 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 main &&
test_commit b &&
git checkout -b sub-c main &&
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 main) &&
git add sub &&
git commit -m a &&
git checkout -b top-b main &&
(cd sub && git checkout sub-b) &&
git add sub &&
git commit -m b &&
git checkout -b top-c main &&
(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
test_expect_success 'recursive merge with submodule' '
(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)
'
# File/submodule conflict
# Commit O: <empty>
# Commit A: path (submodule)
# Commit B: path
# Expected: path/ is submodule and file contents for B's path are somewhere
test_expect_success 'setup file/submodule conflict' '
git init file-submodule &&
(
cd file-submodule &&
git commit --allow-empty -m O &&
git branch A &&
git branch B &&
git checkout B &&
echo content >path &&
git add path &&
git commit -m B &&
git checkout A &&
git init path &&
test_commit -C path world &&
git submodule add ./path &&
git commit -m A
)
'
test_expect_merge_algorithm failure success 'file/submodule conflict' '
test_when_finished "git -C file-submodule reset --hard" &&
(
cd file-submodule &&
git checkout A^0 &&
test_must_fail git merge B^0 &&
git ls-files -s >out &&
test_line_count = 3 out &&
git ls-files -u >out &&
test_line_count = 2 out &&
# path/ is still a submodule
test_path_is_dir path/.git &&
# There is a submodule at "path", so B:path cannot be written
# there. We expect it to be written somewhere in the same
# directory, though, so just grep for its content in all
# files, and ignore "grep: path: Is a directory" message
echo Checking if contents from B:path showed up anywhere &&
grep -q content * 2>/dev/null
)
'
test_expect_success 'file/submodule conflict; merge --abort works afterward' '
test_when_finished "git -C file-submodule reset --hard" &&
(
cd file-submodule &&
git checkout A^0 &&
test_must_fail git merge B^0 >out 2>err &&
test_path_is_file .git/MERGE_HEAD &&
git merge --abort
)
'
# Directory/submodule conflict
# Commit O: <empty>
# Commit A: path (submodule), with sole tracked file named 'world'
# Commit B1: path/file
# Commit B2: path/world
#
# Expected from merge of A & B1:
# Contents under path/ from commit B1 are renamed elsewhere; we do not
# want to write files from one of our tracked directories into a submodule
#
# Expected from merge of A & B2:
# Similar to last merge, but with a slight twist: we don't want paths
# under the submodule to be treated as untracked or in the way.
test_expect_success 'setup directory/submodule conflict' '
git init directory-submodule &&
(
cd directory-submodule &&
git commit --allow-empty -m O &&
git branch A &&
git branch B1 &&
git branch B2 &&
git checkout B1 &&
mkdir path &&
echo contents >path/file &&
git add path/file &&
git commit -m B1 &&
git checkout B2 &&
mkdir path &&
echo contents >path/world &&
git add path/world &&
git commit -m B2 &&
git checkout A &&
git init path &&
test_commit -C path hello world &&
git submodule add ./path &&
git commit -m A
)
'
test_expect_failure 'directory/submodule conflict; keep submodule clean' '
test_when_finished "git -C directory-submodule reset --hard" &&
(
cd directory-submodule &&
git checkout A^0 &&
test_must_fail git merge B1^0 &&
git ls-files -s >out &&
test_line_count = 3 out &&
git ls-files -u >out &&
test_line_count = 1 out &&
# path/ is still a submodule
test_path_is_dir path/.git &&
echo Checking if contents from B1:path/file showed up &&
# Would rather use grep -r, but that is GNU extension...
git ls-files -co | xargs grep -q contents 2>/dev/null &&
# However, B1:path/file should NOT have shown up at path/file,
# because we should not write into the submodule
test_path_is_missing path/file
)
'
test_expect_merge_algorithm failure success !FAIL_PREREQS 'directory/submodule conflict; should not treat submodule files as untracked or in the way' '
test_when_finished "git -C directory-submodule/path reset --hard" &&
test_when_finished "git -C directory-submodule reset --hard" &&
(
cd directory-submodule &&
git checkout A^0 &&
test_must_fail git merge B2^0 >out 2>err &&
# We do not want files within the submodule to prevent the
# merge from starting; we should not be writing to such paths
# anyway.
test_grep ! "refusing to lose untracked file at" err
)
'
test_expect_failure 'directory/submodule conflict; merge --abort works afterward' '
test_when_finished "git -C directory-submodule/path reset --hard" &&
test_when_finished "git -C directory-submodule reset --hard" &&
(
cd directory-submodule &&
git checkout A^0 &&
test_must_fail git merge B2^0 &&
test_path_is_file .git/MERGE_HEAD &&
# merge --abort should succeed, should clear .git/MERGE_HEAD,
# and should not leave behind any conflicted files
git merge --abort &&
test_path_is_missing .git/MERGE_HEAD &&
git ls-files -u >conflicts &&
test_must_be_empty conflicts
)
'
submodule merge: update conflict error message When attempting to merge in a superproject with conflicting submodule pointers that cannot be fast-forwarded or trivially resolved, the merge fails and Git prints an error message that accurately describes the failure, but does not provide steps for the user to resolve the error. Git is left in a conflicted state, which requires the user to: 1. merge submodules or update submodules to an already existing commit that reflects the merge 2. add submodules changes to the superproject 3. finish merging superproject These steps are non-obvious for newer submodule users to figure out based on the error message and neither `git submodule status` nor `git status` provide any useful pointers. Update error message to provide steps to resolve submodule merge conflict. Future work could involve adding an advice flag to the message. Although the message is long, it also has the id of the submodule commit that needs to be merged, which could be useful information for the user. Additionally, 5 merge failures that resulted in an early return have been updated to reflect the status of the merge. 1. Null merge base (null o): CONFLICT_SUBMODULE_NULL_MERGE_BASE added as a new conflict type and will print updated error message. 2. Null merge side a (null a): BUG(). See [1] for discussion 3. Null merge side b (null b): BUG(). See [1] for discussion 4. Submodule not checked out: added NEEDSWORK bit 5. Submodule commits not present: added NEEDSWORK bit The errors with a NEEDSWORK bit deserve a more detailed explanation of how to resolve them. See [2] for more context. [1] https://lore.kernel.org/git/CABPp-BE0qGwUy80dmVszkJQ+tcpfLRW0OZyErymzhZ9+HWY1mw@mail.gmail.com/ [2] https://lore.kernel.org/git/xmqqpmhjjwo9.fsf@gitster.g/ Signed-off-by: Calvin Wan <calvinwan@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-04 22:51:05 +03:00
# Setup:
# - Submodule has 2 commits: a and b
# - Superproject branch 'a' adds and commits submodule pointing to 'commit a'
# - Superproject branch 'b' adds and commits submodule pointing to 'commit b'
# If these two branches are now merged, there is no merge base
test_expect_success 'setup for null merge base' '
mkdir no-merge-base &&
(cd no-merge-base &&
git init &&
mkdir sub &&
(cd sub &&
git init &&
echo "file-a" > file-a &&
git add file-a &&
git commit -m "commit a") &&
git commit --allow-empty -m init &&
git branch init &&
git checkout -b a init &&
git add sub &&
git commit -m "a" &&
git switch main &&
(cd sub &&
echo "file-b" > file-b &&
git add file-b &&
git commit -m "commit b"))
'
test_expect_success 'merging should fail with no merge base' '
(cd no-merge-base &&
git checkout -b b init &&
git add sub &&
git commit -m "b" &&
test_must_fail git merge a 2>actual &&
submodule merge: update conflict error message When attempting to merge in a superproject with conflicting submodule pointers that cannot be fast-forwarded or trivially resolved, the merge fails and Git prints an error message that accurately describes the failure, but does not provide steps for the user to resolve the error. Git is left in a conflicted state, which requires the user to: 1. merge submodules or update submodules to an already existing commit that reflects the merge 2. add submodules changes to the superproject 3. finish merging superproject These steps are non-obvious for newer submodule users to figure out based on the error message and neither `git submodule status` nor `git status` provide any useful pointers. Update error message to provide steps to resolve submodule merge conflict. Future work could involve adding an advice flag to the message. Although the message is long, it also has the id of the submodule commit that needs to be merged, which could be useful information for the user. Additionally, 5 merge failures that resulted in an early return have been updated to reflect the status of the merge. 1. Null merge base (null o): CONFLICT_SUBMODULE_NULL_MERGE_BASE added as a new conflict type and will print updated error message. 2. Null merge side a (null a): BUG(). See [1] for discussion 3. Null merge side b (null b): BUG(). See [1] for discussion 4. Submodule not checked out: added NEEDSWORK bit 5. Submodule commits not present: added NEEDSWORK bit The errors with a NEEDSWORK bit deserve a more detailed explanation of how to resolve them. See [2] for more context. [1] https://lore.kernel.org/git/CABPp-BE0qGwUy80dmVszkJQ+tcpfLRW0OZyErymzhZ9+HWY1mw@mail.gmail.com/ [2] https://lore.kernel.org/git/xmqqpmhjjwo9.fsf@gitster.g/ Signed-off-by: Calvin Wan <calvinwan@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-04 22:51:05 +03:00
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
then
sub_expect="go to submodule (sub), and either merge commit $(git -C sub rev-parse --short HEAD^1)" &&
grep "$sub_expect" actual
fi)
'
test_done