git/t/t7610-mergetool.sh

864 строки
27 KiB
Bash
Исходник Обычный вид История

#!/bin/sh
#
# Copyright (c) 2008 Charles Bailey
#
test_description='git mergetool
Testing basic merge tool invocation'
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
. ./test-lib.sh
# All the mergetool test work by checking out a temporary branch based
# off 'branch1' and then merging in main and checking the results of
# running mergetool
test_expect_success 'setup' '
test_config rerere.enabled true &&
echo main >file1 &&
echo main spaced >"spaced name" &&
echo main file11 >file11 &&
echo main file12 >file12 &&
echo main file13 >file13 &&
echo main file14 >file14 &&
mkdir subdir &&
echo main sub >subdir/file3 &&
test_create_repo submod &&
(
cd submod &&
: >foo &&
git add foo &&
git commit -m "Add foo"
) &&
git submodule add file:///dev/null submod &&
git add file1 "spaced name" file1[1-4] subdir/file3 .gitmodules submod &&
git commit -m "add initial versions" &&
git checkout -b branch1 main &&
git submodule update -N &&
echo branch1 change >file1 &&
echo branch1 newfile >file2 &&
echo branch1 spaced >"spaced name" &&
echo branch1 both added >both &&
echo branch1 change file11 >file11 &&
echo branch1 change file13 >file13 &&
echo branch1 sub >subdir/file3 &&
(
cd submod &&
echo branch1 submodule >bar &&
git add bar &&
git commit -m "Add bar on branch1" &&
git checkout -b submod-branch1
) &&
git add file1 "spaced name" file11 file13 file2 subdir/file3 submod &&
git add both &&
git rm file12 &&
git commit -m "branch1 changes" &&
git checkout -b delete-base branch1 &&
mkdir -p a/a &&
test_write_lines one two 3 4 >a/a/file.txt &&
git add a/a/file.txt &&
git commit -m"base file" &&
git checkout -b move-to-b delete-base &&
mkdir -p b/b &&
git mv a/a/file.txt b/b/file.txt &&
test_write_lines one two 4 >b/b/file.txt &&
git commit -a -m"move to b" &&
git checkout -b move-to-c delete-base &&
mkdir -p c/c &&
git mv a/a/file.txt c/c/file.txt &&
test_write_lines one two 3 >c/c/file.txt &&
git commit -a -m"move to c" &&
git checkout -b stash1 main &&
echo stash1 change file11 >file11 &&
git add file11 &&
git commit -m "stash1 changes" &&
git checkout -b stash2 main &&
echo stash2 change file11 >file11 &&
git add file11 &&
git commit -m "stash2 changes" &&
git checkout main &&
git submodule update -N &&
echo main updated >file1 &&
echo main new >file2 &&
echo main updated spaced >"spaced name" &&
echo main both added >both &&
echo main updated file12 >file12 &&
echo main updated file14 >file14 &&
echo main new sub >subdir/file3 &&
(
cd submod &&
echo main submodule >bar &&
git add bar &&
git commit -m "Add bar on main" &&
git checkout -b submod-main
) &&
git add file1 "spaced name" file12 file14 file2 subdir/file3 submod &&
git add both &&
git rm file11 &&
git commit -m "main updates" &&
git clean -fdx &&
git checkout -b order-file-start main &&
echo start >a &&
echo start >b &&
git add a b &&
git commit -m start &&
git checkout -b order-file-side1 order-file-start &&
echo side1 >a &&
echo side1 >b &&
git add a b &&
git commit -m side1 &&
git checkout -b order-file-side2 order-file-start &&
echo side2 >a &&
echo side2 >b &&
git add a b &&
git commit -m side2 &&
git config merge.tool mytool &&
git config mergetool.mytool.cmd "cat \"\$REMOTE\" >\"\$MERGED\"" &&
git config mergetool.mytool.trustExitCode true &&
git config mergetool.mybase.cmd "cat \"\$BASE\" >\"\$MERGED\"" &&
git config mergetool.mybase.trustExitCode true
'
test_expect_success 'custom mergetool' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
git submodule update -N &&
test_must_fail git merge main &&
yes "" | git mergetool both &&
yes "" | git mergetool file1 file1 &&
yes "" | git mergetool file2 "spaced name" &&
yes "" | git mergetool subdir/file3 &&
yes "d" | git mergetool file11 &&
yes "d" | git mergetool file12 &&
yes "l" | git mergetool submod &&
echo "main updated" >expect &&
test_cmp expect file1 &&
echo "main new" >expect &&
test_cmp expect file2 &&
echo "main new sub" >expect &&
test_cmp expect subdir/file3 &&
echo "branch1 submodule" >expect &&
test_cmp expect submod/bar &&
git commit -m "branch1 resolved with mergetool"
'
test_expect_success 'gui mergetool' '
test_config merge.guitool myguitool &&
test_config mergetool.myguitool.cmd "(printf \"gui \" && cat \"\$REMOTE\") >\"\$MERGED\"" &&
test_config mergetool.myguitool.trustExitCode true &&
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
git submodule update -N &&
test_must_fail git merge main &&
yes "" | git mergetool --gui both &&
yes "" | git mergetool -g file1 file1 &&
yes "" | git mergetool --gui file2 "spaced name" &&
yes "" | git mergetool --gui subdir/file3 &&
yes "d" | git mergetool --gui file11 &&
yes "d" | git mergetool --gui file12 &&
yes "l" | git mergetool --gui submod &&
echo "gui main updated" >expect &&
test_cmp expect file1 &&
echo "gui main new" >expect &&
test_cmp expect file2 &&
echo "gui main new sub" >expect &&
test_cmp expect subdir/file3 &&
echo "branch1 submodule" >expect &&
test_cmp expect submod/bar &&
git commit -m "branch1 resolved with mergetool"
'
test_expect_success 'gui mergetool without merge.guitool set falls back to merge.tool' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
git submodule update -N &&
test_must_fail git merge main &&
yes "" | git mergetool --gui both &&
yes "" | git mergetool -g file1 file1 &&
yes "" | git mergetool --gui file2 "spaced name" &&
yes "" | git mergetool --gui subdir/file3 &&
yes "d" | git mergetool --gui file11 &&
yes "d" | git mergetool --gui file12 &&
yes "l" | git mergetool --gui submod &&
echo "main updated" >expect &&
test_cmp expect file1 &&
echo "main new" >expect &&
test_cmp expect file2 &&
echo "main new sub" >expect &&
test_cmp expect subdir/file3 &&
echo "branch1 submodule" >expect &&
test_cmp expect submod/bar &&
git commit -m "branch1 resolved with mergetool"
'
test_expect_success 'mergetool crlf' '
test_when_finished "git reset --hard" &&
# This test_config line must go after the above reset line so that
# core.autocrlf is unconfigured before reset runs. (The
# test_config command uses test_when_finished internally and
# test_when_finished is LIFO.)
test_config core.autocrlf true &&
git checkout -b test$test_count branch1 &&
test_must_fail git merge main &&
yes "" | git mergetool file1 &&
yes "" | git mergetool file2 &&
yes "" | git mergetool "spaced name" &&
yes "" | git mergetool both &&
yes "" | git mergetool subdir/file3 &&
yes "d" | git mergetool file11 &&
yes "d" | git mergetool file12 &&
yes "r" | git mergetool submod &&
test "$(printf x | cat file1 -)" = "$(printf "main updated\r\nx")" &&
test "$(printf x | cat file2 -)" = "$(printf "main new\r\nx")" &&
test "$(printf x | cat subdir/file3 -)" = "$(printf "main new sub\r\nx")" &&
git submodule update -N &&
echo "main submodule" >expect &&
test_cmp expect submod/bar &&
git commit -m "branch1 resolved with mergetool - autocrlf"
'
test_expect_success 'mergetool in subdir' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
git submodule update -N &&
(
cd subdir &&
test_must_fail git merge main &&
yes "" | git mergetool file3 &&
echo "main new sub" >expect &&
test_cmp expect file3
)
'
test_expect_success 'mergetool on file in parent dir' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
git submodule update -N &&
(
cd subdir &&
test_must_fail git merge main &&
yes "" | git mergetool file3 &&
yes "" | git mergetool ../file1 &&
yes "" | git mergetool ../file2 ../spaced\ name &&
yes "" | git mergetool ../both &&
yes "d" | git mergetool ../file11 &&
yes "d" | git mergetool ../file12 &&
yes "l" | git mergetool ../submod &&
echo "main updated" >expect &&
test_cmp expect ../file1 &&
echo "main new" >expect &&
test_cmp expect ../file2 &&
echo "branch1 submodule" >expect &&
test_cmp expect ../submod/bar &&
git commit -m "branch1 resolved with mergetool - subdir"
)
'
test_expect_success 'mergetool skips autoresolved' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
git submodule update -N &&
test_must_fail git merge main &&
test -n "$(git ls-files -u)" &&
yes "d" | git mergetool file11 &&
yes "d" | git mergetool file12 &&
yes "l" | git mergetool submod &&
output="$(git mergetool --no-prompt)" &&
test "$output" = "No files need merging"
'
test_expect_success 'mergetool merges all from subdir (rerere disabled)' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
test_config rerere.enabled false &&
(
cd subdir &&
test_must_fail git merge main &&
yes "r" | git mergetool ../submod &&
yes "d" "d" | git mergetool --no-prompt &&
echo "main updated" >expect &&
test_cmp expect ../file1 &&
echo "main new" >expect &&
test_cmp expect ../file2 &&
echo "main new sub" >expect &&
test_cmp expect file3 &&
( cd .. && git submodule update -N ) &&
echo "main submodule" >expect &&
test_cmp expect ../submod/bar &&
git commit -m "branch2 resolved by mergetool from subdir"
)
'
test_expect_success 'mergetool merges all from subdir (rerere enabled)' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
test_config rerere.enabled true &&
rm -rf .git/rr-cache &&
(
cd subdir &&
test_must_fail git merge main &&
yes "r" | git mergetool ../submod &&
yes "d" "d" | git mergetool --no-prompt &&
echo "main updated" >expect &&
test_cmp expect ../file1 &&
echo "main new" >expect &&
test_cmp expect ../file2 &&
echo "main new sub" >expect &&
test_cmp expect file3 &&
( cd .. && git submodule update -N ) &&
echo "main submodule" >expect &&
test_cmp expect ../submod/bar &&
git commit -m "branch2 resolved by mergetool from subdir"
)
'
test_expect_success 'mergetool skips resolved paths when rerere is active' '
test_when_finished "git reset --hard" &&
test_config rerere.enabled true &&
rm -rf .git/rr-cache &&
git checkout -b test$test_count branch1 &&
git submodule update -N &&
test_must_fail git merge main &&
yes "l" | git mergetool --no-prompt submod &&
yes "d" "d" | git mergetool --no-prompt &&
git submodule update -N &&
output="$(yes "n" | git mergetool --no-prompt)" &&
test "$output" = "No files need merging"
'
test_expect_success 'conflicted stash sets up rerere' '
test_when_finished "git reset --hard" &&
test_config rerere.enabled true &&
git checkout stash1 &&
echo "Conflicting stash content" >file11 &&
git stash &&
git checkout --detach stash2 &&
test_must_fail git stash apply &&
test -n "$(git ls-files -u)" &&
conflicts="$(git rerere remaining)" &&
test "$conflicts" = "file11" &&
output="$(git mergetool --no-prompt)" &&
test "$output" != "No files need merging" &&
git commit -am "save the stash resolution" &&
git reset --hard stash2 &&
test_must_fail git stash apply &&
test -n "$(git ls-files -u)" &&
conflicts="$(git rerere remaining)" &&
test -z "$conflicts" &&
output="$(git mergetool --no-prompt)" &&
test "$output" = "No files need merging"
'
test_expect_success 'mergetool takes partial path' '
test_when_finished "git reset --hard" &&
test_config rerere.enabled false &&
git checkout -b test$test_count branch1 &&
git submodule update -N &&
test_must_fail git merge main &&
yes "" | git mergetool subdir &&
echo "main new sub" >expect &&
test_cmp expect subdir/file3
'
test_expect_success 'mergetool delete/delete conflict' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count move-to-c &&
test_must_fail git merge move-to-b &&
echo d | git mergetool a/a/file.txt &&
! test -f a/a/file.txt &&
git reset --hard &&
test_must_fail git merge move-to-b &&
echo m | git mergetool a/a/file.txt &&
test -f b/b/file.txt &&
git reset --hard &&
test_must_fail git merge move-to-b &&
! echo a | git mergetool a/a/file.txt &&
! test -f a/a/file.txt
'
test_expect_success 'mergetool produces no errors when keepBackup is used' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count move-to-c &&
test_config mergetool.keepBackup true &&
test_must_fail git merge move-to-b &&
echo d | git mergetool a/a/file.txt 2>actual &&
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-20 00:57:25 +03:00
test_must_be_empty actual &&
! test -d a
'
test_expect_success 'mergetool honors tempfile config for deleted files' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count move-to-c &&
test_config mergetool.keepTemporaries false &&
test_must_fail git merge move-to-b &&
echo d | git mergetool a/a/file.txt &&
! test -d a
'
test_expect_success 'mergetool keeps tempfiles when aborting delete/delete' '
test_when_finished "git reset --hard" &&
test_when_finished "git clean -fdx" &&
git checkout -b test$test_count move-to-c &&
test_config mergetool.keepTemporaries true &&
test_must_fail git merge move-to-b &&
! test_write_lines a n | git mergetool a/a/file.txt &&
test -d a/a &&
cat >expect <<-\EOF &&
file_BASE_.txt
file_LOCAL_.txt
file_REMOTE_.txt
EOF
ls -1 a/a | sed -e "s/[0-9]*//g" >actual &&
test_cmp expect actual
'
test_expect_success 'deleted vs modified submodule' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
git submodule update -N &&
mv submod submod-movedaside &&
git rm --cached submod &&
git commit -m "Submodule deleted from branch" &&
git checkout -b test$test_count.a test$test_count &&
test_must_fail git merge main &&
test -n "$(git ls-files -u)" &&
yes "" | git mergetool file1 file2 spaced\ name subdir/file3 &&
yes "" | git mergetool both &&
yes "d" | git mergetool file11 file12 &&
yes "r" | git mergetool submod &&
rmdir submod && mv submod-movedaside submod &&
echo "branch1 submodule" >expect &&
test_cmp expect submod/bar &&
git submodule update -N &&
echo "main submodule" >expect &&
test_cmp expect submod/bar &&
output="$(git mergetool --no-prompt)" &&
test "$output" = "No files need merging" &&
git commit -m "Merge resolved by keeping module" &&
mv submod submod-movedaside &&
git checkout -b test$test_count.b test$test_count &&
git submodule update -N &&
test_must_fail git merge main &&
test -n "$(git ls-files -u)" &&
yes "" | git mergetool file1 file2 spaced\ name subdir/file3 &&
yes "" | git mergetool both &&
yes "d" | git mergetool file11 file12 &&
yes "l" | git mergetool submod &&
test ! -e submod &&
output="$(git mergetool --no-prompt)" &&
test "$output" = "No files need merging" &&
git commit -m "Merge resolved by deleting module" &&
mv submod-movedaside submod &&
git checkout -b test$test_count.c main &&
git submodule update -N &&
test_must_fail git merge test$test_count &&
test -n "$(git ls-files -u)" &&
yes "" | git mergetool file1 file2 spaced\ name subdir/file3 &&
yes "" | git mergetool both &&
yes "d" | git mergetool file11 file12 &&
yes "r" | git mergetool submod &&
test ! -e submod &&
test -d submod.orig &&
git submodule update -N &&
output="$(git mergetool --no-prompt)" &&
test "$output" = "No files need merging" &&
git commit -m "Merge resolved by deleting module" &&
mv submod.orig submod &&
git checkout -b test$test_count.d main &&
git submodule update -N &&
test_must_fail git merge test$test_count &&
test -n "$(git ls-files -u)" &&
yes "" | git mergetool file1 file2 spaced\ name subdir/file3 &&
yes "" | git mergetool both &&
yes "d" | git mergetool file11 file12 &&
yes "l" | git mergetool submod &&
echo "main submodule" >expect &&
test_cmp expect submod/bar &&
git submodule update -N &&
echo "main submodule" >expect &&
test_cmp expect submod/bar &&
output="$(git mergetool --no-prompt)" &&
test "$output" = "No files need merging" &&
git commit -m "Merge resolved by keeping module"
'
test_expect_success 'file vs modified submodule' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
git submodule update -N &&
mv submod submod-movedaside &&
git rm --cached submod &&
echo not a submodule >submod &&
git add submod &&
git commit -m "Submodule path becomes file" &&
git checkout -b test$test_count.a branch1 &&
test_must_fail git merge main &&
test -n "$(git ls-files -u)" &&
yes "" | git mergetool file1 file2 spaced\ name subdir/file3 &&
yes "" | git mergetool both &&
yes "d" | git mergetool file11 file12 &&
yes "r" | git mergetool submod &&
rmdir submod && mv submod-movedaside submod &&
echo "branch1 submodule" >expect &&
test_cmp expect submod/bar &&
git submodule update -N &&
echo "main submodule" >expect &&
test_cmp expect submod/bar &&
output="$(git mergetool --no-prompt)" &&
test "$output" = "No files need merging" &&
git commit -m "Merge resolved by keeping module" &&
mv submod submod-movedaside &&
git checkout -b test$test_count.b test$test_count &&
test_must_fail git merge main &&
test -n "$(git ls-files -u)" &&
yes "" | git mergetool file1 file2 spaced\ name subdir/file3 &&
yes "" | git mergetool both &&
yes "d" | git mergetool file11 file12 &&
merge tests: expect improved directory/file conflict handling in ort merge-recursive.c is built on the idea of running unpack_trees() and then "doing minor touch-ups" to get the result. Unfortunately, unpack_trees() was run in an update-as-it-goes mode, leading merge-recursive.c to follow suit and end up with an immediate evaluation and fix-it-up-as-you-go design. Some things like directory/file conflicts are not well representable in the index data structure, and required special extra code to handle. But then when it was discovered that rename/delete conflicts could also be involved in directory/file conflicts, the special directory/file conflict handling code had to be copied to the rename/delete codepath. ...and then it had to be copied for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it still missed some. Further, when it was discovered that there were also file/submodule conflicts and submodule/directory conflicts, we needed to copy the special submodule handling code to all the special cases throughout the codebase. And then it was discovered that our handling of directory/file conflicts was suboptimal because it would create untracked files to store the contents of the conflicting file, which would not be cleaned up if someone were to run a 'git merge --abort' or 'git rebase --abort'. It was also difficult or scary to try to add or remove the index entries corresponding to these files given the directory/file conflict in the index. But changing merge-recursive.c to handle these correctly was a royal pain because there were so many sites in the code with similar but not identical code for handling directory/file/submodule conflicts that would all need to be updated. I have worked hard to push all directory/file/submodule conflict handling in merge-ort through a single codepath, and avoid creating untracked files for storing tracked content (it does record things at alternate paths, but makes sure they have higher-order stages in the index). Since updating merge-recursive is too much work and we don't want to destabilize it, instead update the testsuite to have different expectations for relevant directory/file/submodule conflict tests. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 20:01:37 +03:00
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
then
yes "c" | git mergetool submod~HEAD &&
git rm submod &&
git mv submod~HEAD submod
else
yes "l" | git mergetool submod
fi &&
git submodule update -N &&
echo "not a submodule" >expect &&
test_cmp expect submod &&
output="$(git mergetool --no-prompt)" &&
test "$output" = "No files need merging" &&
git commit -m "Merge resolved by keeping file" &&
git checkout -b test$test_count.c main &&
rmdir submod && mv submod-movedaside submod &&
test ! -e submod.orig &&
git submodule update -N &&
test_must_fail git merge test$test_count &&
test -n "$(git ls-files -u)" &&
yes "" | git mergetool file1 file2 spaced\ name subdir/file3 &&
yes "" | git mergetool both &&
yes "d" | git mergetool file11 file12 &&
merge tests: expect improved directory/file conflict handling in ort merge-recursive.c is built on the idea of running unpack_trees() and then "doing minor touch-ups" to get the result. Unfortunately, unpack_trees() was run in an update-as-it-goes mode, leading merge-recursive.c to follow suit and end up with an immediate evaluation and fix-it-up-as-you-go design. Some things like directory/file conflicts are not well representable in the index data structure, and required special extra code to handle. But then when it was discovered that rename/delete conflicts could also be involved in directory/file conflicts, the special directory/file conflict handling code had to be copied to the rename/delete codepath. ...and then it had to be copied for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it still missed some. Further, when it was discovered that there were also file/submodule conflicts and submodule/directory conflicts, we needed to copy the special submodule handling code to all the special cases throughout the codebase. And then it was discovered that our handling of directory/file conflicts was suboptimal because it would create untracked files to store the contents of the conflicting file, which would not be cleaned up if someone were to run a 'git merge --abort' or 'git rebase --abort'. It was also difficult or scary to try to add or remove the index entries corresponding to these files given the directory/file conflict in the index. But changing merge-recursive.c to handle these correctly was a royal pain because there were so many sites in the code with similar but not identical code for handling directory/file/submodule conflicts that would all need to be updated. I have worked hard to push all directory/file/submodule conflict handling in merge-ort through a single codepath, and avoid creating untracked files for storing tracked content (it does record things at alternate paths, but makes sure they have higher-order stages in the index). Since updating merge-recursive is too much work and we don't want to destabilize it, instead update the testsuite to have different expectations for relevant directory/file/submodule conflict tests. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 20:01:37 +03:00
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
then
mv submod submod.orig &&
git rm --cached submod &&
yes "c" | git mergetool submod~test19 &&
git mv submod~test19 submod
else
yes "r" | git mergetool submod
fi &&
test -d submod.orig &&
git submodule update -N &&
echo "not a submodule" >expect &&
test_cmp expect submod &&
output="$(git mergetool --no-prompt)" &&
test "$output" = "No files need merging" &&
git commit -m "Merge resolved by keeping file" &&
git checkout -b test$test_count.d main &&
rmdir submod && mv submod.orig submod &&
git submodule update -N &&
test_must_fail git merge test$test_count &&
test -n "$(git ls-files -u)" &&
yes "" | git mergetool file1 file2 spaced\ name subdir/file3 &&
yes "" | git mergetool both &&
yes "d" | git mergetool file11 file12 &&
yes "l" | git mergetool submod &&
merge tests: expect improved directory/file conflict handling in ort merge-recursive.c is built on the idea of running unpack_trees() and then "doing minor touch-ups" to get the result. Unfortunately, unpack_trees() was run in an update-as-it-goes mode, leading merge-recursive.c to follow suit and end up with an immediate evaluation and fix-it-up-as-you-go design. Some things like directory/file conflicts are not well representable in the index data structure, and required special extra code to handle. But then when it was discovered that rename/delete conflicts could also be involved in directory/file conflicts, the special directory/file conflict handling code had to be copied to the rename/delete codepath. ...and then it had to be copied for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it still missed some. Further, when it was discovered that there were also file/submodule conflicts and submodule/directory conflicts, we needed to copy the special submodule handling code to all the special cases throughout the codebase. And then it was discovered that our handling of directory/file conflicts was suboptimal because it would create untracked files to store the contents of the conflicting file, which would not be cleaned up if someone were to run a 'git merge --abort' or 'git rebase --abort'. It was also difficult or scary to try to add or remove the index entries corresponding to these files given the directory/file conflict in the index. But changing merge-recursive.c to handle these correctly was a royal pain because there were so many sites in the code with similar but not identical code for handling directory/file/submodule conflicts that would all need to be updated. I have worked hard to push all directory/file/submodule conflict handling in merge-ort through a single codepath, and avoid creating untracked files for storing tracked content (it does record things at alternate paths, but makes sure they have higher-order stages in the index). Since updating merge-recursive is too much work and we don't want to destabilize it, instead update the testsuite to have different expectations for relevant directory/file/submodule conflict tests. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 20:01:37 +03:00
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
then
yes "d" | git mergetool submod~test19
fi &&
echo "main submodule" >expect &&
test_cmp expect submod/bar &&
git submodule update -N &&
echo "main submodule" >expect &&
test_cmp expect submod/bar &&
output="$(git mergetool --no-prompt)" &&
test "$output" = "No files need merging" &&
git commit -m "Merge resolved by keeping module"
'
test_expect_success 'submodule in subdirectory' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
git submodule update -N &&
(
cd subdir &&
test_create_repo subdir_module &&
(
cd subdir_module &&
: >file15 &&
git add file15 &&
git commit -m "add initial versions"
)
) &&
test_when_finished "rm -rf subdir/subdir_module" &&
git submodule add file:///dev/null subdir/subdir_module &&
git add subdir/subdir_module &&
git commit -m "add submodule in subdirectory" &&
git checkout -b test$test_count.a test$test_count &&
git submodule update -N &&
(
cd subdir/subdir_module &&
git checkout -b super10.a &&
echo test$test_count.a >file15 &&
git add file15 &&
git commit -m "on branch 10.a"
) &&
git add subdir/subdir_module &&
git commit -m "change submodule in subdirectory on test$test_count.a" &&
git checkout -b test$test_count.b test$test_count &&
git submodule update -N &&
(
cd subdir/subdir_module &&
git checkout -b super10.b &&
echo test$test_count.b >file15 &&
git add file15 &&
git commit -m "on branch 10.b"
) &&
git add subdir/subdir_module &&
git commit -m "change submodule in subdirectory on test$test_count.b" &&
test_must_fail git merge test$test_count.a &&
(
cd subdir &&
yes "l" | git mergetool subdir_module
) &&
echo "test$test_count.b" >expect &&
test_cmp expect subdir/subdir_module/file15 &&
git submodule update -N &&
echo "test$test_count.b" >expect &&
test_cmp expect subdir/subdir_module/file15 &&
git reset --hard &&
git submodule update -N &&
test_must_fail git merge test$test_count.a &&
yes "r" | git mergetool subdir/subdir_module &&
echo "test$test_count.b" >expect &&
test_cmp expect subdir/subdir_module/file15 &&
git submodule update -N &&
echo "test$test_count.a" >expect &&
test_cmp expect subdir/subdir_module/file15 &&
git commit -m "branch1 resolved with mergetool"
'
test_expect_success 'directory vs modified submodule' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
mv submod submod-movedaside &&
git rm --cached submod &&
mkdir submod &&
echo not a submodule >submod/file16 &&
git add submod/file16 &&
git commit -m "Submodule path becomes directory" &&
test_must_fail git merge main &&
test -n "$(git ls-files -u)" &&
yes "l" | git mergetool submod &&
echo "not a submodule" >expect &&
test_cmp expect submod/file16 &&
rm -rf submod.orig &&
git reset --hard &&
test_must_fail git merge main &&
test -n "$(git ls-files -u)" &&
test ! -e submod.orig &&
merge tests: expect improved directory/file conflict handling in ort merge-recursive.c is built on the idea of running unpack_trees() and then "doing minor touch-ups" to get the result. Unfortunately, unpack_trees() was run in an update-as-it-goes mode, leading merge-recursive.c to follow suit and end up with an immediate evaluation and fix-it-up-as-you-go design. Some things like directory/file conflicts are not well representable in the index data structure, and required special extra code to handle. But then when it was discovered that rename/delete conflicts could also be involved in directory/file conflicts, the special directory/file conflict handling code had to be copied to the rename/delete codepath. ...and then it had to be copied for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it still missed some. Further, when it was discovered that there were also file/submodule conflicts and submodule/directory conflicts, we needed to copy the special submodule handling code to all the special cases throughout the codebase. And then it was discovered that our handling of directory/file conflicts was suboptimal because it would create untracked files to store the contents of the conflicting file, which would not be cleaned up if someone were to run a 'git merge --abort' or 'git rebase --abort'. It was also difficult or scary to try to add or remove the index entries corresponding to these files given the directory/file conflict in the index. But changing merge-recursive.c to handle these correctly was a royal pain because there were so many sites in the code with similar but not identical code for handling directory/file/submodule conflicts that would all need to be updated. I have worked hard to push all directory/file/submodule conflict handling in merge-ort through a single codepath, and avoid creating untracked files for storing tracked content (it does record things at alternate paths, but makes sure they have higher-order stages in the index). Since updating merge-recursive is too much work and we don't want to destabilize it, instead update the testsuite to have different expectations for relevant directory/file/submodule conflict tests. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 20:01:37 +03:00
if test "$GIT_TEST_MERGE_ALGORITHM" = ort
then
yes "r" | git mergetool submod~main &&
merge tests: expect improved directory/file conflict handling in ort merge-recursive.c is built on the idea of running unpack_trees() and then "doing minor touch-ups" to get the result. Unfortunately, unpack_trees() was run in an update-as-it-goes mode, leading merge-recursive.c to follow suit and end up with an immediate evaluation and fix-it-up-as-you-go design. Some things like directory/file conflicts are not well representable in the index data structure, and required special extra code to handle. But then when it was discovered that rename/delete conflicts could also be involved in directory/file conflicts, the special directory/file conflict handling code had to be copied to the rename/delete codepath. ...and then it had to be copied for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it still missed some. Further, when it was discovered that there were also file/submodule conflicts and submodule/directory conflicts, we needed to copy the special submodule handling code to all the special cases throughout the codebase. And then it was discovered that our handling of directory/file conflicts was suboptimal because it would create untracked files to store the contents of the conflicting file, which would not be cleaned up if someone were to run a 'git merge --abort' or 'git rebase --abort'. It was also difficult or scary to try to add or remove the index entries corresponding to these files given the directory/file conflict in the index. But changing merge-recursive.c to handle these correctly was a royal pain because there were so many sites in the code with similar but not identical code for handling directory/file/submodule conflicts that would all need to be updated. I have worked hard to push all directory/file/submodule conflict handling in merge-ort through a single codepath, and avoid creating untracked files for storing tracked content (it does record things at alternate paths, but makes sure they have higher-order stages in the index). Since updating merge-recursive is too much work and we don't want to destabilize it, instead update the testsuite to have different expectations for relevant directory/file/submodule conflict tests. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 20:01:37 +03:00
git mv submod submod.orig &&
git mv submod~main submod
merge tests: expect improved directory/file conflict handling in ort merge-recursive.c is built on the idea of running unpack_trees() and then "doing minor touch-ups" to get the result. Unfortunately, unpack_trees() was run in an update-as-it-goes mode, leading merge-recursive.c to follow suit and end up with an immediate evaluation and fix-it-up-as-you-go design. Some things like directory/file conflicts are not well representable in the index data structure, and required special extra code to handle. But then when it was discovered that rename/delete conflicts could also be involved in directory/file conflicts, the special directory/file conflict handling code had to be copied to the rename/delete codepath. ...and then it had to be copied for modify/delete, and for rename/rename(1to2) conflicts, ...and yet it still missed some. Further, when it was discovered that there were also file/submodule conflicts and submodule/directory conflicts, we needed to copy the special submodule handling code to all the special cases throughout the codebase. And then it was discovered that our handling of directory/file conflicts was suboptimal because it would create untracked files to store the contents of the conflicting file, which would not be cleaned up if someone were to run a 'git merge --abort' or 'git rebase --abort'. It was also difficult or scary to try to add or remove the index entries corresponding to these files given the directory/file conflict in the index. But changing merge-recursive.c to handle these correctly was a royal pain because there were so many sites in the code with similar but not identical code for handling directory/file/submodule conflicts that would all need to be updated. I have worked hard to push all directory/file/submodule conflict handling in merge-ort through a single codepath, and avoid creating untracked files for storing tracked content (it does record things at alternate paths, but makes sure they have higher-order stages in the index). Since updating merge-recursive is too much work and we don't want to destabilize it, instead update the testsuite to have different expectations for relevant directory/file/submodule conflict tests. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-26 20:01:37 +03:00
else
yes "r" | git mergetool submod
fi &&
test -d submod.orig &&
echo "not a submodule" >expect &&
test_cmp expect submod.orig/file16 &&
rm -r submod.orig &&
mv submod-movedaside/.git submod &&
( cd submod && git clean -f && git reset --hard ) &&
git submodule update -N &&
echo "main submodule" >expect &&
test_cmp expect submod/bar &&
git reset --hard &&
rm -rf submod-movedaside &&
git checkout -b test$test_count.c main &&
git submodule update -N &&
test_must_fail git merge test$test_count &&
test -n "$(git ls-files -u)" &&
yes "l" | git mergetool submod &&
git submodule update -N &&
echo "main submodule" >expect &&
test_cmp expect submod/bar &&
git reset --hard &&
git submodule update -N &&
test_must_fail git merge test$test_count &&
test -n "$(git ls-files -u)" &&
test ! -e submod.orig &&
yes "r" | git mergetool submod &&
echo "not a submodule" >expect &&
test_cmp expect submod/file16 &&
git reset --hard main &&
( cd submod && git clean -f && git reset --hard ) &&
git submodule update -N
'
test_expect_success 'file with no base' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
test_must_fail git merge main &&
git mergetool --no-prompt --tool mybase -- both &&
test_must_be_empty both
'
test_expect_success 'custom commands override built-ins' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
test_config mergetool.defaults.cmd "cat \"\$REMOTE\" >\"\$MERGED\"" &&
test_config mergetool.defaults.trustExitCode true &&
test_must_fail git merge main &&
git mergetool --no-prompt --tool defaults -- both &&
echo main both added >expected &&
test_cmp expected both
'
test_expect_success 'filenames seen by tools start with ./' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
test_config mergetool.writeToTemp false &&
test_config mergetool.myecho.cmd "echo \"\$LOCAL\"" &&
test_config mergetool.myecho.trustExitCode true &&
test_must_fail git merge main &&
git mergetool --no-prompt --tool myecho -- both >actual &&
grep ^\./both_LOCAL_ actual
'
test_lazy_prereq MKTEMP '
tempdir=$(mktemp -d -t foo.XXXXXX) &&
test -d "$tempdir" &&
rmdir "$tempdir"
'
test_expect_success MKTEMP 'temporary filenames are used with mergetool.writeToTemp' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count branch1 &&
test_config mergetool.writeToTemp true &&
test_config mergetool.myecho.cmd "echo \"\$LOCAL\"" &&
test_config mergetool.myecho.trustExitCode true &&
test_must_fail git merge main &&
git mergetool --no-prompt --tool myecho -- both >actual &&
! grep ^\./both_LOCAL_ actual &&
grep /both_LOCAL_ actual
'
test_expect_success 'diff.orderFile configuration is honored' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count order-file-side2 &&
test_config diff.orderFile order-file &&
test_config mergetool.myecho.cmd "echo \"\$LOCAL\"" &&
test_config mergetool.myecho.trustExitCode true &&
echo b >order-file &&
echo a >>order-file &&
test_must_fail git merge order-file-side1 &&
cat >expect <<-\EOF &&
Merging:
b
a
EOF
# make sure "order-file" that is ambiguous between
# rev and path is understood correctly.
git branch order-file HEAD &&
git mergetool --no-prompt --tool myecho >output &&
git grep --no-index -h -A2 Merging: output >actual &&
test_cmp expect actual
'
test_expect_success 'mergetool -Oorder-file is honored' '
test_when_finished "git reset --hard" &&
git checkout -b test$test_count order-file-side2 &&
test_config diff.orderFile order-file &&
test_config mergetool.myecho.cmd "echo \"\$LOCAL\"" &&
test_config mergetool.myecho.trustExitCode true &&
echo b >order-file &&
echo a >>order-file &&
test_must_fail git merge order-file-side1 &&
cat >expect <<-\EOF &&
Merging:
a
b
EOF
git mergetool -O/dev/null --no-prompt --tool myecho >output &&
git grep --no-index -h -A2 Merging: output >actual &&
test_cmp expect actual &&
git reset --hard &&
git config --unset diff.orderFile &&
test_must_fail git merge order-file-side1 &&
cat >expect <<-\EOF &&
Merging:
b
a
EOF
git mergetool -Oorder-file --no-prompt --tool myecho >output &&
git grep --no-index -h -A2 Merging: output >actual &&
test_cmp expect actual
'
mergetool--lib: fix '--tool-help' to correctly show available tools Commit 83bbf9b92e (mergetool--lib: improve support for vimdiff-style tool variants, 2020-07-29) introduced a regression in the output of `git mergetool --tool-help` and `git difftool --tool-help` [1]. In function 'show_tool_names' in git-mergetool--lib.sh, we loop over the supported mergetools and their variants and accumulate them in the variable 'variants', separating them with a literal '\n'. The code then uses 'echo $variants' to turn these '\n' into newlines, but this behaviour is not portable, it just happens to work in some shells, like dash(1)'s 'echo' builtin. For shells in which 'echo' does not turn '\n' into newlines, the end result is that the only tools that are shown are the existing variants (except the last variant alphabetically), since the variants are separated by actual newlines in '$variants' because of the several 'echo' calls in mergetools/{bc,vimdiff}::list_tool_variants. Fix this bug by embedding an actual line feed into `variants` in show_tool_names(). While at it, replace `sort | uniq` by `sort -u`. To prevent future regressions, add a simple test that checks that a few known tools are correctly shown (let's avoid counting the total number of tools to lessen the maintenance burden when new tools are added or if '--tool-help' learns additional logic, like hiding tools depending on the current platform). [1] https://lore.kernel.org/git/CADtb9DyozjgAsdFYL8fFBEWmq7iz4=prZYVUdH9W-J5CKVS4OA@mail.gmail.com/ Reported-by: Philippe Blain <levraiphilippeblain@gmail.com> Based-on-patch-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-07 04:09:05 +03:00
test_expect_success 'mergetool --tool-help shows recognized tools' '
# Check a few known tools are correctly shown
git mergetool --tool-help >mergetools &&
grep vimdiff mergetools &&
grep vimdiff3 mergetools &&
grep gvimdiff2 mergetools &&
grep araxis mergetools &&
grep xxdiff mergetools &&
grep meld mergetools
'
mergetool: add hideResolved configuration The purpose of a mergetool is to help the user resolve any conflicts that Git cannot automatically resolve. If there is a conflict that must be resolved manually Git will write a file named MERGED which contains everything Git was able to resolve by itself and also everything that it was not able to resolve wrapped in conflict markers. One way to think of MERGED is as a two- or three-way diff. If each "side" of the conflict markers is separately extracted an external tool can represent those conflicts as a side-by-side diff. However many mergetools instead diff LOCAL and REMOTE both of which contain versions of the file from before the merge. Since the conflicts Git resolved automatically are not present it forces the user to manually re-resolve those conflicts. Some mergetools also show MERGED but often only for reference and not as the focal point to resolve the conflicts. This adds a `mergetool.hideResolved` flag that will overwrite LOCAL and REMOTE with each corresponding "side" of a conflicted file and thus hide all conflicts that Git was able to resolve itself. Overwriting these files will immediately benefit any mergetool that uses them without requiring any changes to the tool. No adverse effects were noted in a small survey of popular mergetools[1] so this behavior defaults to `true`. However it can be globally disabled by setting `mergetool.hideResolved` to `false`. [1] https://www.eseth.org/2020/mergetools.html https://github.com/whiteinge/eseth/blob/c884424769fffb05d87afb33b2cf80cecb4044c3/2020/mergetools.md Original-implementation-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Seth House <seth@eseth.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-09 23:07:10 +03:00
test_expect_success 'mergetool hideResolved' '
test_config mergetool.hideResolved true &&
test_when_finished "git reset --hard" &&
git checkout -b test${test_count}_b main &&
mergetool: add hideResolved configuration The purpose of a mergetool is to help the user resolve any conflicts that Git cannot automatically resolve. If there is a conflict that must be resolved manually Git will write a file named MERGED which contains everything Git was able to resolve by itself and also everything that it was not able to resolve wrapped in conflict markers. One way to think of MERGED is as a two- or three-way diff. If each "side" of the conflict markers is separately extracted an external tool can represent those conflicts as a side-by-side diff. However many mergetools instead diff LOCAL and REMOTE both of which contain versions of the file from before the merge. Since the conflicts Git resolved automatically are not present it forces the user to manually re-resolve those conflicts. Some mergetools also show MERGED but often only for reference and not as the focal point to resolve the conflicts. This adds a `mergetool.hideResolved` flag that will overwrite LOCAL and REMOTE with each corresponding "side" of a conflicted file and thus hide all conflicts that Git was able to resolve itself. Overwriting these files will immediately benefit any mergetool that uses them without requiring any changes to the tool. No adverse effects were noted in a small survey of popular mergetools[1] so this behavior defaults to `true`. However it can be globally disabled by setting `mergetool.hideResolved` to `false`. [1] https://www.eseth.org/2020/mergetools.html https://github.com/whiteinge/eseth/blob/c884424769fffb05d87afb33b2cf80cecb4044c3/2020/mergetools.md Original-implementation-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Seth House <seth@eseth.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-09 23:07:10 +03:00
test_write_lines >file1 base "" a &&
git commit -a -m "base" &&
test_write_lines >file1 base "" c &&
git commit -a -m "remote update" &&
git checkout -b test${test_count}_a HEAD~ &&
test_write_lines >file1 local "" b &&
git commit -a -m "local update" &&
test_must_fail git merge test${test_count}_b &&
yes "" | git mergetool file1 &&
test_write_lines >expect local "" c &&
test_cmp expect file1 &&
git commit -m "test resolved with mergetool"
'
test_done