Add Code Compare v2.80.4 as a merge / diff tool for Windows
PATCH 1/1 Add Code Compare v2.80.4 as a merge / diff tool for Windows
Code Compare is a commercial file comparison tool for Windows, see
http://www.devart.com/codecompare/
Version 2.80.4 added support for command line arguments preceded by a dash instead of a slash. This is required for Git for Windows because slashes in command line arguments get mangled with according to these rules:
http://www.mingw.org/wiki/Posix_path_conversion
--- Documentation/merge-config.txt | 8 ++++---- contrib/completion/git-completion.bash | 2 +- git-mergetool--lib.sh | 2 +- mergetools/codecompare | 25 +++++++++++++++++++++++++ 4 files changed, 31 insertions(+), 6 deletions(-) create mode 100644 mergetools/codecompare
Documentation/merge-config.txt +4 -4
@@ -54,10 +54,10 @@ merge.stat:: merge.tool:: Controls which merge resolution program is used by linkgit:git-mergetool[1]. Valid built-in values are: "araxis", - "bc3", "diffuse", "ecmerge", "emerge", "gvimdiff", "kdiff3", "meld", - "opendiff", "p4merge", "tkdiff", "tortoisemerge", "vimdiff" - and "xxdiff". Any other value is treated is custom merge tool - and there must be a corresponding mergetool.<tool>.cmd option. + "bc3", "codecompare", "diffuse", "ecmerge", "emerge", "gvimdiff", + "kdiff3", "meld", "opendiff", "p4merge", "tkdiff", "tortoisemerge", + "vimdiff" and "xxdiff". Any other value is treated is custom merge + tool and there must be a corresponding mergetool.<tool>.cmd option. merge.verbosity:: Controls the amount of output shown by the recursive merge
contrib/completion/git-completion.bash +1 -1
@@ -1071,7 +1071,7 @@ _git_diff () } __git_mergetools_common="diffuse ecmerge emerge kdiff3 meld opendiff - tkdiff vimdiff gvimdiff xxdiff araxis p4merge bc3 + tkdiff vimdiff gvimdiff xxdiff araxis p4merge bc3 codecompare " _git_difftool ()
git-mergetool--lib.sh +1 -1
@@ -126,7 +126,7 @@ list_merge_tool_candidates () { else tools="opendiff kdiff3 tkdiff xxdiff meld $tools" fi - tools="$tools gvimdiff diffuse ecmerge p4merge araxis bc3" + tools="$tools gvimdiff diffuse ecmerge p4merge araxis bc3 codecompare" fi case "${VISUAL:-$EDITOR}" in *vim*)
mergetools/codecompare new file +25 -0
@@ -0,0 +1,25 @@ +diff_cmd () { + "$merge_tool_path" "$LOCAL" "$REMOTE" +} + +merge_cmd () { + touch "$BACKUP" + if $base_present + then + "$merge_tool_path" -MF="$LOCAL" -TF="$REMOTE" -BF="$BASE" \ + -RF="$MERGED" + else + "$merge_tool_path" -MF="$LOCAL" -TF="$REMOTE" \ + -RF="$MERGED" + fi + check_unchanged +} + +translate_merge_tool_path() { + if merge_mode + then + echo CodeMerge + else + echo CodeCompare + fi +}
Signature · 1 line
1.7.11.msysgit.3
Quoted 29 lines · Sebastian Schuberth
Code Compare is a commercial file comparison tool for Windows, see
http://www.devart.com/codecompare/
Version 2.80.4 added support for command line arguments preceded by a dash instead of a slash. This is required for Git for Windows because slashes in command line arguments get mangled with according to these rules:
http://www.mingw.org/wiki/Posix_path_conversion
Signed-off-by Sebastian Schuberth <[email protected]>--- Documentation/merge-config.txt | 8 ++++---- contrib/completion/git-completion.bash | 2 +- git-mergetool--lib.sh | 2 +- mergetools/codecompare | 25 +++++++++++++++++++++++++ 4 files changed, 31 insertions(+), 6 deletions(-) create mode 100644 mergetools/codecompareDocumentation/merge-config.txt +0
-1@@ -54,10 +54,10 @@ merge.stat:: merge.tool:: Controls which merge resolution program is used by linkgit:git-mergetool[1]. Valid built-in values are: "araxis", - "bc3", "diffuse", "ecmerge", "emerge", "gvimdiff", "kdiff3", "meld",
Documentation/merge-config.txt merge.stat:: · line 63
Quoted 10 lines
Documentation/merge-config.txt +4
-3- "opendiff", "p4merge", "tkdiff", "tortoisemerge", "vimdiff" - and "xxdiff". Any other value is treated is custom merge tool - and there must be a corresponding mergetool.<tool>.cmd option. + "bc3", "codecompare", "diffuse", "ecmerge", "emerge", "gvimdiff", + "kdiff3", "meld", "opendiff", "p4merge", "tkdiff", "tortoisemerge", + "vimdiff" and "xxdiff". Any other value is treated is custom merge + tool and there must be a corresponding mergetool.<tool>.cmd option. merge.verbosity:: Controls the amount of output shown by the recursive merge
I do not have a strong reason to vote for or against inclusion of yet another tool as mergetool backends (read: Meh), but what this patch does to Documentation/merge-config.txt is actively unwelcome.
As we discussed earlier in
http://thread.gmane.org/gmane.comp.version-control.git/201913/focus=201976
the longer term direction is to reduce the names of tools listed there.
I am somewhat saddened to find your name in that thread; you should have been aware of that discussion when you wrote this patch.
Quoted 2 lines · Junio C Hamano
I do not have a strong reason to vote for or against inclusion of yet another tool as mergetool backends (read: Meh), but what this
That sounds almost as if you'd like to keep the number of directly supported mergetools small (I'm not talking about about the length of the list of mergetools in the docs right now). I was always thinking, the more mergetools, the better. Do you think differently?
Quoted 11 lines
patch does to
Documentation/merge-config.txtis actively unwelcome.As we discussed earlier in
http://thread.gmane.org/gmane.comp.version-control.git/201913/focus=201976the longer term direction is to reduce the names of tools listed there.
I am somewhat saddened to find your name in that thread; you should have been aware of that discussion when you wrote this patch.
I still agree that not listing all mergetools in multiple places is a good thing. But doing the whole stuff of extending --tool-help for git-mergetool and git-difftool to return a simple list that can be used in git-completion.bash etc. IMHO is a separate topic and out of scope of this patch.
If it helps to accept the patch, I can send a v2 that changes merge-config.txt and diff-config.txt to refer to "git-mergetool --tool-help" and "git-difftool --tool-help" instead of naming any actual tools.
Signature · 1 line
Sebastian Schuberth
Quoted 9 lines · Sebastian Schuberth
Quoted 2 lines · Junio C Hamano
I do not have a strong reason to vote for or against inclusion of yet another tool as mergetool backends (read: Meh), but what this
That sounds almost as if you'd like to keep the number of directly supported mergetools small (I'm not talking about about the length of the list of mergetools in the docs right now). I was always thinking, the more mergetools, the better. Do you think differently?
It depends on the pros-and-cons between the cost of forcing many people to see a list of supported backends with yet one more item (the list only grows and rarely shrinks) and the benefit of the subset of users who can now use it. I couldn't measure how widely the particular commercial program is used from your proposed commit log message, and that is where my "for or against" comes from.
Quoted 9 lines
Quoted 9 lines
patch does to
Documentation/merge-config.txtis actively unwelcome.As we discussed earlier in
http://thread.gmane.org/gmane.comp.version-control.git/201913/focus=201976the longer term direction is to reduce the names of tools listed there.
Quoted 8 lines
Quoted 2 lines
I am somewhat saddened to find your name in that thread; you should have been aware of that discussion when you wrote this patch.
I still agree that not listing all mergetools in multiple places is a good thing. But doing the whole stuff of extending --tool-help for git-mergetool and git-difftool to return a simple list that can be used in git-completion.bash etc. IMHO is a separate topic and out of scope of this patch.
Exactly. If you know that is the long term direction, I would have preferred you _not_ to touch any existing descriptions of the tools (not even changing them to refer to "--tool-help") in this patch, in order to avoid unnecessary conflicts with the topic of unifying the list of tool backends, which can be written and cooked separately.
Thanks.
Quoted 11 lines · Junio C Hamano
Quoted 5 lines
I still agree that not listing all mergetools in multiple places is a good thing. But doing the whole stuff of extending --tool-help for git-mergetool and git-difftool to return a simple list that can be used in git-completion.bash etc. IMHO is a separate topic and out of scope of this patch.
Exactly. If you know that is the long term direction, I would have preferred you _not_ to touch any existing descriptions of the tools (not even changing them to refer to "--tool-help") in this patch, in order to avoid unnecessary conflicts with the topic of unifying the list of tool backends, which can be written and cooked separately.
To the the best of my knowledge there currently no such topic underway, and even if it was, it would be unclear how long it would take for integration. If I was not touching the existing descriptions of the tools, and a Git version was to be released after accepting my patch but before the --tool-help topic is merged, that would leave the documentation in a wrong state. I was just trying to be consistent by also touching the descriptions, which IMHO is the correct thing to do in the short term, as you yourself say the topic to make use of --tool-help is a long term goal.
Signature · 1 line
Sebastian Schuberth
Quoted 14 lines · Sebastian Schuberth
Quoted 11 lines · Junio C Hamano
Quoted 5 lines
I still agree that not listing all mergetools in multiple places is a good thing. But doing the whole stuff of extending --tool-help for git-mergetool and git-difftool to return a simple list that can be used in git-completion.bash etc. IMHO is a separate topic and out of scope of this patch.
Exactly. If you know that is the long term direction, I would have preferred you _not_ to touch any existing descriptions of the tools (not even changing them to refer to "--tool-help") in this patch, in order to avoid unnecessary conflicts with the topic of unifying the list of tool backends, which can be written and cooked separately.
Quoted 9 lines
To the the best of my knowledge there currently no such topic underway, and even if it was, it would be unclear how long it would take for integration. If I was not touching the existing descriptions of the tools, and a Git version was to be released after accepting my patch but before the --tool-help topic is merged, that would leave the documentation in a wrong state. I was just trying to be consistent by also touching the descriptions, which IMHO is the correct thing to do in the short term, as you yourself say the topic to make use of --tool-help is a long term goal.
Thanks Sebastian.
I think your patch would be good, so long as we leave the descriptions alone.
If you could please re-roll to add the new scriptlet without touching the docs then that would be very helpful.
I have a separate patch to update the mergetool documentation for --tool-help which I will send shortly.
I have another topic (--symlinks) in next upon which it is based.
Signature · 1 line
David
PATCH v2 1/1 Add Code Compare v2.80.4 as a merge / diff tool for Windows
Code Compare is a commercial file comparison tool for Windows, see
http://www.devart.com/codecompare/
Version 2.80.4 added support for command line arguments preceded by a dash instead of a slash. This is required for Git for Windows because slashes in command line arguments get mangled with according to these rules:
http://www.mingw.org/wiki/Posix_path_conversion
--- contrib/completion/git-completion.bash | 2 +- git-mergetool--lib.sh | 2 +- mergetools/codecompare | 25 +++++++++++++++++++++++++ 3 files changed, 27 insertions(+), 2 deletions(-) create mode 100644 mergetools/codecompare
contrib/completion/git-completion.bash +1 -1
@@ -1071,7 +1071,7 @@ _git_diff () } __git_mergetools_common="diffuse ecmerge emerge kdiff3 meld opendiff - tkdiff vimdiff gvimdiff xxdiff araxis p4merge bc3 + tkdiff vimdiff gvimdiff xxdiff araxis p4merge bc3 codecompare " _git_difftool ()
git-mergetool--lib.sh +1 -1
@@ -126,7 +126,7 @@ list_merge_tool_candidates () { else tools="opendiff kdiff3 tkdiff xxdiff meld $tools" fi - tools="$tools gvimdiff diffuse ecmerge p4merge araxis bc3" + tools="$tools gvimdiff diffuse ecmerge p4merge araxis bc3 codecompare" fi case "${VISUAL:-$EDITOR}" in *vim*)
mergetools/codecompare new file +25 -0
@@ -0,0 +1,25 @@ +diff_cmd () { + "$merge_tool_path" "$LOCAL" "$REMOTE" +} + +merge_cmd () { + touch "$BACKUP" + if $base_present + then + "$merge_tool_path" -MF="$LOCAL" -TF="$REMOTE" -BF="$BASE" \ + -RF="$MERGED" + else + "$merge_tool_path" -MF="$LOCAL" -TF="$REMOTE" \ + -RF="$MERGED" + fi + check_unchanged +} + +translate_merge_tool_path() { + if merge_mode + then + echo CodeMerge + else + echo CodeCompare + fi +}
Signature · 1 line
1.7.9.6 (Apple Git-31.1)