patchAdd 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
>
> Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
> ---
>  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
>
> diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
> index 861bd6f..e9e0d55 100644
> --- a/Documentation/merge-config.txt
> +++ b/Documentation/merge-config.txt
> @@ -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

> 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.

> On Wed, Aug 8, 2012 at 11:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> 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?

>> 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.
>
> 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.

>> 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.

> On Thu, Aug 9, 2012 at 6:03 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>>> 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.