summaryrefslogtreecommitdiff
path: root/t/t7610-mergetool.sh
AgeCommit message (Collapse)AuthorFilesLines
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>
2010-11-09tests: add missing &&Libravatar Jonathan Nieder1-1/+1
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-24t7610: cd inside subshell instead of aroundLibravatar Brian Gernhardt1-23/+26
Instead of using `cd dir && (...) && cd..` use `(cd dir && ...)` This ensures that the test doesn't get caught in the subdirectory if there is an error in the subshell. Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-17mergetool: Skip autoresolved pathsLibravatar David Aguilar1-12/+34
When mergetool is run without path limiters it loops over each entry in 'git ls-files -u'. This includes autoresolved paths. Teach mergetool to only merge files listed in 'rerere status' when rerere is enabled. There are some subtle but harmless changes in behavior. We now call cd_to_toplevel when no paths are given. We do this because 'rerere status' paths are always relative to the root. This is beneficial for the non-rerere use as well in that mergetool now runs against all unmerged files regardless of the current directory. This also slightly tweaks the output when run without paths to be more readable. The old output: Merging the files: foo bar baz The new output: Merging: foo bar baz Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-31mergetool: fix running mergetool in sub-directoriesLibravatar Charles Bailey1-1/+1
The previous fix to mergetool to use checkout-index instead of cat-file broke running mergetool anywhere except the root of the repository. This fixes it by using the correct relative paths for temporary files and index paths. Signed-off-by: Charles Bailey <charles@hashpling.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-31mergetool: Add a test for running mergetool in a sub-directoryLibravatar Charles Bailey1-19/+51
Signed-off-by: Charles Bailey <charles@hashpling.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-27mergetool: respect autocrlf by using checkout-indexLibravatar Charles Bailey1-2/+13
Previously, git mergetool used cat-file which does not perform git to worktree conversion. This changes mergetool to use git checkout-index instead which means that the temporary files used for mergetool use the correct line endings for the platform. Signed-off-by: Charles Bailey <charles@hashpling.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-03tests: use "git xyzzy" form (t7200 - t9001)Libravatar Nanako Shiraishi1-1/+1
Converts tests between t7201-t9001. Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13t/: Use "test_must_fail git" instead of "! git"Libravatar Stephan Beyer1-1/+1
This patch changes every occurrence of "! git" -- with the meaning that a git call has to gracefully fail -- into "test_must_fail git". This is useful to - make sure the test does not fail because of a signal, e.g. SIGSEGV, and - advertise the use of "test_must_fail" for new tests. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-04Fix executable bits in t/ scriptsLibravatar Junio C Hamano1-0/+0
Pointed out by Ramsay Jones. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-05Add a very basic test script for git mergetoolLibravatar Charles Bailey1-0/+46
Signed-off-by: Charles Bailey <charles@hashpling.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>