summaryrefslogtreecommitdiff
path: root/t/t7610-mergetool.sh
AgeCommit message (Collapse)AuthorFilesLines
2020-10-26merge tests: expect improved directory/file conflict handling in ortLibravatar Elijah Newren1-3/+29
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>
2019-06-12t7610-mergetool: use test_cmp instead of test $(cat file) = $txtLibravatar Johannes Sixt1-45/+90
Fix that anti-pattern by a sequence of echo and test_cmp. The patch was generated with this command: sed -i -e '/test.*(cat/s/^\(\t*\)test "..cat \(.*\))" = \(".*"\)\(.*\)/\1echo \3 >expect \&\&\n\1test_cmp expect \2\4/' t7610-mergetool.sh This helps on Windows, where test_cmp avoids spawning a process when there is no difference. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-06-10t7610-mergetool: do not place pipelines headed by `yes` in subshellsLibravatar Johannes Sixt1-85/+85
Subshells for pipelines are not required. This can save a number of processes (if the shell does not optimize it away anyway). The patch was generated with the command sed -i 's/( *\(yes.*[^ ]\) *) *\&\&/\1 \&\&/' t7610-mergetool.sh with a manual fixup of the case having no && at the end. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-13mergetool: fallback to tool when guitool unavailableLibravatar Denton Liu1-0/+19
In git-difftool, if the tool is called with --gui but `diff.guitool` is not set, it falls back to `diff.tool`. Make git-mergetool also fallback from `merge.guitool` to `merge.tool` if the former is undefined. If git-difftool, when called with `--gui`, were to use `get_configured_mergetool` in a future patch, it would also get the fallback behavior in the following precedence: 1. diff.guitool 2. merge.guitool 3. diff.tool 4. merge.tool The behavior for when difftool or mergetool are called without `--gui` should be identical with or without this patch. Note that the search loop could be written as sections="merge" keys="tool" if diff_mode then sections="diff $sections" fi if gui_mode then keys="guitool $keys" fi merge_tool=$( IFS=' ' for key in $keys do for section in $sections do selected=$(git config $section.$key) if test -n "$selected" then echo "$selected" return fi done done) which would make adding a mode in the future much easier. However, adding a new mode will likely never happen as it is highly discouraged so, as a result, it is written in its current form so that it is more readable for future readers. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-25t7610: add mergetool --gui testsLibravatar Denton Liu1-0/+22
In 063f2bdbf7 (mergetool: accept -g/--[no-]gui as arguments, 2018-10-24), mergetool was taught the --gui option but no tests were added to ensure that it was working properly. Add a test to ensure that it works. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-25t7610: unsuppress outputLibravatar Denton Liu1-61/+61
The output for commands used to be suppressed by redirecting both stdout and stderr to /dev/null. However, this should not happen since the output is useful for debugging and, without the "-v" flag, test scripts don't output anyway. Unsuppress the output by removing the redirections to /dev/null. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-27Merge branch 'sg/test-must-be-empty'Libravatar Junio C Hamano1-2/+1
Test fixes. * sg/test-must-be-empty: tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' tests: use 'test_must_be_empty' instead of 'test_cmp /dev/null <out>' tests: use 'test_must_be_empty' instead of 'test ! -s' tests: use 'test_must_be_empty' instead of '! test -s'
2018-08-21tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'Libravatar SZEDER Gábor1-2/+1
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-20Merge branch 'ab/test-must-be-empty-for-master'Libravatar Junio C Hamano1-2/+1
Test updates. * ab/test-must-be-empty-for-master: tests: make use of the test_must_be_empty function
2018-07-30tests: make use of the test_must_be_empty functionLibravatar Ævar Arnfjörð Bjarmason1-2/+1
Change various tests that use an idiom of the form: >expect && test_cmp expect actual To instead use: test_must_be_empty actual The test_must_be_empty() wrapper was introduced in ca8d148daf ("test: test_must_be_empty helper", 2013-06-09). Many of these tests have been added after that time. This was mostly found with, and manually pruned from: git grep '^\s+>.*expect.* &&$' t Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-03t: use test_write_lines() instead of series of 'echo' commandsLibravatar Eric Sunshine1-4/+4
These tests employ a noisy subshell (with missing &&-chain) to feed input into Git commands or files: (echo a; echo b; echo c) | git some-command ... Simplify by taking advantage of test_write_lines(): test_write_lines a b c | git some-command ... Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-07tests: fix diff order arguments in test_cmpLibravatar Stefan Beller1-2/+2
Fix the argument order for test_cmp. When given the expected result first the diff shows the actual output with '+' and the expectation with '-', which is the convention for our tests. Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-18Merge branch 'rh/mergetool-regression-fix'Libravatar Junio C Hamano1-114/+165
"git mergetool" without any pathspec on the command line that is run from a subdirectory became no-op in Git v2.11 by mistake, which has been fixed. * rh/mergetool-regression-fix: mergetool: fix running in subdir when rerere enabled mergetool: take the "-O" out of $orderfile t7610: add test case for rerere+mergetool+subdir bug t7610: spell 'git reset --hard' consistently t7610: don't assume the checked-out commit t7610: always work on a test-specific branch t7610: delete some now-unnecessary 'git reset --hard' lines t7610: run 'git reset --hard' after each test to clean up t7610: don't rely on state from previous test t7610: use test_when_finished for cleanup tasks t7610: move setup code to the 'setup' test case t7610: update branch names to match test number rev-parse doc: pass "--" to rev-parse in the --prefix example .mailmap: record canonical email for Richard Hansen
2017-01-18Merge branch 'pb/test-must-fail-is-for-git'Libravatar Junio C Hamano1-1/+1
Test cleanup. * pb/test-must-fail-is-for-git: t9813: avoid using pipes don't use test_must_fail with grep
2017-01-10mergetool: fix running in subdir when rerere enabledLibravatar Richard Hansen1-1/+6
"git mergetool" (without any pathspec on the command line) that is not run from the top-level of the working tree no longer works in Git v2.11, failing to get the list of unmerged paths from the output of "git rerere remaining". This regression was introduced by 57937f70a0 ("mergetool: honor diff.orderFile", 2016-10-07). This is because the pathnames output by the 'git rerere remaining' command are relative to the top-level directory but the 'git diff --name-only' command expects its pathname arguments to be relative to the current working directory. To make everything consistent, cd_to_toplevel before running 'git diff --name-only' and adjust any relative pathnames. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: add test case for rerere+mergetool+subdir bugLibravatar Richard Hansen1-1/+20
If rerere is enabled and mergetool is run from a subdirectory, mergetool always prints "No files need merging". Add an expected failure test case for this situation. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: spell 'git reset --hard' consistentlyLibravatar Richard Hansen1-18/+19
Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: don't assume the checked-out commitLibravatar Richard Hansen1-6/+6
Always check out the required commit at the beginning of the test so that a failure in a previous test does not cause the test to work off of the wrong commit. This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: always work on a test-specific branchLibravatar Richard Hansen1-2/+8
Create and use a test-specific branch when the test might create a commit. This is not always necessary for correctness, but it improves debuggability by ensuring a commit created by test #N shows up on the testN branch, not the branch for test #N-1. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: delete some now-unnecessary 'git reset --hard' linesLibravatar Richard Hansen1-2/+0
Tests now always run 'git reset --hard' at the end (even if they fail), so it's no longer necessary to run 'git reset --hard' at the beginning of a test. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: run 'git reset --hard' after each test to clean upLibravatar Richard Hansen1-0/+8
Use test_when_finished to run 'git reset --hard' after each test so that the repository is left in a saner state for the next test. This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: don't rely on state from previous testLibravatar Richard Hansen1-0/+6
If the repository must be in a particular state (beyond what is already done by the 'setup' test case) before the test can run, make the necessary repository changes in the test script even if it means duplicating some lines of code from the previous test case. This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: use test_when_finished for cleanup tasksLibravatar Richard Hansen1-34/+37
This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: move setup code to the 'setup' test caseLibravatar Richard Hansen1-30/+35
Multiple test cases depend on these hunks, so move them to the 'setup' test case. This is a step toward making the tests more independent so that if one test fails it doesn't cause subsequent tests to fail. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-10t7610: update branch names to match test numberLibravatar Richard Hansen1-41/+41
Rename the testNN branches so that NN matches the test number. This should make it easier to troubleshoot test issues. Use $test_count to keep this future-proof. Signed-off-by: Richard Hansen <hansenr@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-07don't use test_must_fail with grepLibravatar Pranit Bauva1-1/+1
test_must_fail should only be used for testing git commands. To test the failure of other commands use `!`. Reported-by: Stefan Beller <sbeller@google.com> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-16Merge branch 'ak/lazy-prereq-mktemp'Libravatar Junio C Hamano1-1/+2
Test code clean-up. * ak/lazy-prereq-mktemp: t7610: clean up foo.XXXXXX tmpdir
2016-11-29t7610: clean up foo.XXXXXX tmpdirLibravatar Jeff King1-1/+2
The lazy prereq for MKTEMP uses "mktemp -t" to see if mergetool's internal mktemp call will be able to run. But unlike the call inside mergetool, we do not ever bother to clean up the result, and the /tmp of git developers will slowly fill up with "foo.XXXXXX" directories as they run the test suite over and over. Let's clean up the directory after we've verified its creation. Note that we don't use test_when_finished here, and instead just make rmdir part of the &&-chain. We should only remove something that we're confident we just created. A failure in the middle of the chain either means there's nothing to clean up, or we are very confused and should err on the side of caution. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-11mergetool: honor -O<orderfile>Libravatar David Aguilar1-0/+27
Teach mergetool to pass "-O<orderfile>" down to `git diff` when specified on the command-line. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: David Aguilar <davvid@gmail.com> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-11mergetool: honor diff.orderFileLibravatar David Aguilar1-0/+33
Teach mergetool to get the list of files to edit via `diff` so that we gain support for diff.orderFile. Suggested-by: Luis Gutierrez <luisgutz@gmail.com> Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: David Aguilar <davvid@gmail.com> Reviewed-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-06t7610: test for mktemp before test executionLibravatar Armin Kunaschik1-1/+6
mktemp is not available on all platforms, so the test 'temporary filenames are used with mergetool.writeToTemp' fails there. This patch does not replace mktemp but just disables the test that otherwise would fail. mergetool checks itself before executing mktemp and reports an error. Signed-off-by: Armin Kunaschik <megabreit@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-10mergetool: honor tempfile configuration when resolving delete conflictsLibravatar David Aguilar1-0/+25
Teach resolve_deleted_merge() to honor the mergetool.keepBackup and mergetool.keepTemporaries configuration knobs. This ensures that the worktree is kept pristine when resolving deletion conflicts with the variables both set to false. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-10mergetool: support delete/delete conflictsLibravatar David Aguilar1-0/+39
If two branches each move a file into different directories then mergetool will fail because it assumes that the file being merged, and its parent directory, are present in the worktree. Create the merge file's parent directory to allow using the deleted base version of the file for merge resolution when encountering a delete/delete conflict. The end result is that a delete/delete conflict is presented for the user to resolve. Reported-by: Joe Einertson <joe@kidblog.org> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-08t7610: don't use test_config in a subshellLibravatar John Keeping1-1/+1
test_config uses test_when_finished to reset the configuration after the test, but this does not work inside a subshell. This does not cause a problem here because the first thing the next test does is to set this config variable itself, but we are about to add a check that will complain when test_when_finished is used in a subshell. In this case, "subdir" not a submodule so test_config has the same effect when run at the top level and can simply be moved out of the subshell. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-21Merge branch 'da/mergetool-temporary-directory'Libravatar Junio C Hamano1-0/+23
Allow a temporary directory specified to be used while running "git mergetool" backend. * da/mergetool-temporary-directory: t7610-mergetool: add test cases for mergetool.writeToTemp mergetool: add an option for writing to a temporary directory
2014-10-16t7610-mergetool: add test cases for mergetool.writeToTempLibravatar David Aguilar1-0/+23
Add tests to ensure that filenames start with "./" when mergetool.writeToTemp is false and do not start with "./" when mergetool.writeToTemp is true. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-16t7610-mergetool: use test_config to isolate testsLibravatar David Aguilar1-5/+3
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-15t7610-mergetool: prefer test_config over git configLibravatar David Aguilar1-11/+9
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-15t7610-mergetool: add missing && and remove commented-out codeLibravatar David Aguilar1-8/+2
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-15t7610-mergetool: use tabs instead of a mix of tabs and spacesLibravatar David Aguilar1-459/+459
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06rm: delete .gitmodules entry of submodules removed from the work treeLibravatar Jens Lehmann1-3/+3
Currently using "git rm" on a submodule removes the submodule's work tree from that of the superproject and the gitlink from the index. But the submodule's section in .gitmodules is left untouched, which is a leftover of the now removed submodule and might irritate users (as opposed to the setting in .git/config, this must stay as a reminder that the user showed interest in this submodule so it will be repopulated later when an older commit is checked out). Let "git rm" help the user by not only removing the submodule from the work tree but by also removing the "submodule.<submodule name>" section from the .gitmodules file and stage both. This doesn't happen when the "--cached" option is used, as it would modify the work tree. This also silently does nothing when no .gitmodules file is found and only issues a warning when it doesn't have a section for this submodule. This is because the user might just use plain gitlinks without the .gitmodules file or has already removed the section by hand before issuing the "git rm" command (in which case the warning reminds him that rm would have done that for him). Only when .gitmodules is found and contains merge conflicts the rm command will fail and tell the user to resolve the conflict before trying again. Also extend the man page to inform the user about this new feature. While at it promote the submodule sub-section to a chapter as it made not much sense under "REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM". In t7610 three uses of "git rm submod" had to be replaced with "git rm --cached submod" because that test expects .gitmodules and the work tree to stay untouched. Also in t7400 the tests for the remaining settings in the .gitmodules file had to be changed to assert that these settings are missing. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-12Correct common spelling mistakes in comments and testsLibravatar Stefano Lattarini1-1/+1
Most of these were found using Lucas De Marchi's codespell tool. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-01Merge branch 'da/mergetool-custom'Libravatar Junio C Hamano1-0/+13
The actual external command to run for mergetool backend can be specified with difftool/mergetool.$name.cmd configuration variables, but this mechanism was ignored for the backends we natively support. * da/mergetool-custom: mergetool--lib: Allow custom commands to override built-ins
2012-09-25mergetool--lib: Allow custom commands to override built-insLibravatar David Aguilar1-0/+13
Allow users to override the default commands provided by the mergetools/* scriptlets. Users occasionally run into problems where they expect to be able to override the built-in tool names. The documentation does not explicitly mention that built-ins cannot be overridden, so it's easy to assume that it should work. Lift this restriction so that built-in tools are handled the same way as user-configured tools. Add tests to guarantee this behavior. A nice benefit of this change is that it protects users from having future versions of git trump their custom configuration with a new built-in tool. C.f.: http://stackoverflow.com/questions/7435002/mergetool-from-gitconfig-being-ignored http://thread.gmane.org/gmane.comp.version-control.msysgit/13188 http://thread.gmane.org/gmane.comp.version-control.git/148267 Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-17stash: invoke rerere in case of conflictLibravatar Phil Hord1-1/+1
"stash apply" directly calls a backend merge function which does not automatically invoke rerere. This confuses mergetool when leftover rerere state is left behind from previous merges. Invoke rerere explicitly when we encounter a conflict during stash apply. This turns the test introduced by the previous commit to succeed. Signed-off-by: Phil Hord <hordp@cisco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-17test: git-stash conflict sets up rerereLibravatar Phil Hord1-0/+38
Add a test to make sure that a conflicted "stash apply" invokes rerere to record the conflicts and resolve the the files it can (the current code doesn't, so the test is marked as failing). Without correct state recorded for rerere, mergetool may be confused, causing it to think no files have conflicts even though they do. This condition is not verified by this test since a subsequent commit will change the behavior to enable rerere for stash conflicts. Also, the next test expected us to finish up with a reset, which is impossible to do if we fail (as we must) and it's an unreasonable expectation anyway. Begin the next test with a reset of its own instead. Signed-off-by: Phil Hord <hordp@cisco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-23mergetool: Provide an empty file when neededLibravatar David Aguilar1-1/+27
Some merge tools cannot cope when $LOCAL, $BASE, or $REMOTE are missing. $BASE can be missing when two branches independently add the same filename. Provide an empty file to make these tools happy. When a delete/modify conflict occurs, $LOCAL and $REMOTE can also be missing. We have special case code to handle such case so this change may not affect that codepath, but try to be consistent and create an empty file for them anyway. Reported-by: Jason Wenger <jcwenger@gmail.com> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-26mergetool: Use args as pathspec to unmerged filesLibravatar Jonathon Mah1-18/+40
Mergetool now treats its path arguments as a pathspec (like other git subcommands), restricting action to the given files and directories. Files matching the pathspec are filtered so mergetool only acts on unmerged paths; previously it would assume each path argument was in an unresolved state, and get confused when it couldn't check out their other stages. Running "git mergetool subdir" will prompt to resolve all conflicted blobs under subdir. Signed-off-by: Jonathon Mah <me@JonathonMah.com> Acked-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13mergetool: Teach about submodulesLibravatar Jonathon Mah1-3/+287
When the index has conflicted submodules, mergetool used to mildly clobber the module, renaming it to mymodule.BACKUP.nnnn, then failing to copy it non-recursively. Recognize submodules and offer a resolution instead: Submodule merge conflict for 'Shared': {local}: submodule commit ad9f12e3e6205381bf2163a793d1e596a9e211d0 {remote}: submodule commit f5893fb70ec5646efcd9aa643c5136753ac89253 Use (l)ocal or (r)emote, or (a)bort? Selecting a commit will stage it, but not update the submodule (as git does had there been no conflict). Type changes are also supported, should the path be a submodule on one side, and a file, symlink, directory, or deleted on the other. Signed-off-by: Jonathon Mah <me@JonathonMah.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-16mergetool: don't skip modify/remove conflictsLibravatar Martin von Zweigbergk1-6/+34
Since bb0a484 (mergetool: Skip autoresolved paths, 2010-08-17), mergetool uses different ways of figuring out the list of files with merge conflicts depending on whether rerere is active. If rerere is active, mergetool will use 'git rerere status' to list the files with remaining conflicts. However, the output from that command does not list conflicts of types that rerere does not handle, such as modify/remove conflicts. Another problem with solely relying on the output from 'git rerere status' is that, for new conflicts that are not yet known to rerere, the output from the command will list the files even after adding them to the index. This means that if the conflicts in some files have been resolved and 'git mergetool' is run again, it will ask the user something like the following for each of those files. file1: file does not need merging Continue merging other unresolved paths (y/n) ? Solve both of these problems by replacing the call to 'git rerere status' with a call to the new 'git rerere remaining' that was introduced in the previous commit. Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>