Re: [PATCH 2/2] mergetool: Don't assume paths are unmerged
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:51:31
Jonathon Mah [off-list ref] writes:
Like commit, mergetool now treats its path arguments as restricting operation to the listed paths. Running "git mergetool subdir" will prompt to resolve all conflicted blobs under subdir. Previously mergetool would assume each path was in an unresolved state, and get confused when it couldn't check out their other stages. Signed-off-by: Jonathon Mah <redacted> ---
This does two unrelated things, no? - Given the name of a file from the command line, current mergetool gets confused if the given file is not in a conflicted state (bugfix). - Instead of taking command line arguments as literal filenames, treat them as pathspec like any sane git subcommand does, allowing the users more flexibility (new feature). And the title of the patch advertises only the first point. Using the command line argument as pathspec may make a lot of sense, and code reduction in git-mergetool.sh with this patch may also be a good change.
quoted hunk
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt index 8c79ae8..f1f4e7a 100644 --- a/Documentation/git-mergetool.txt +++ b/Documentation/git-mergetool.txt@@ -16,9 +16,10 @@ Use `git mergetool` to run one of several merge utilities to resolve merge conflicts. It is typically run after 'git merge'. If one or more <file> parameters are given, the merge tool program will -be run to resolve differences on each file. If no <file> names are -specified, 'git mergetool' will run the merge tool program on every file -with merge conflicts. +be run to resolve differences on each file (skipping those without +conflicts). Specifying a directory will include all unresolved files in +that path. If no <file> names are specified, 'git mergetool' will run +the merge tool program on every file with merge conflicts.
The documentation may also have to reword <file> written back in the days when they were literal filenames, not pathspecs.
+ matches=$(git ls-files -u -- "$1" | sed -e 's/^[^ ]* //' | sort -u)
Would we want to catch and signal a typo like this? git mergetool Mkaefile git mergetool Documentaiton/ when there is a conflict in Makefile and some file in Documentation/ directory, and user obviously wanted to name them but botched typing? I think you are just letting these typos silently go.
quoted hunk
@@ -392,7 +410,7 @@ test_expect_success 'directory vs modified submodule' ' test "$(cat submod/file16)" = "not a submodule" && rm -rf submod.orig && - git reset --hard && + git reset --hard >/dev/null 2>&1 &&
What is the justification for this change? Please do not make "sh txxx.sh -v" less useful.