On Thu, Aug 9, 2012 at 9:22 AM, Sebastian Schuberth
wrote:
> On Thu, Aug 9, 2012 at 6:03 PM, Junio C Hamano 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
On Thu, Aug 9, 2012 at 6:03 PM, Junio C Hamano 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
Sebastian Schuberth writes:
> On Wed, Aug 8, 2012 at 11:26 PM, Junio C Hamano 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
On Wed, Aug 8, 2012 at 11:26 PM, Junio C Hamano 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 ta
Sebastian Schuberth writes:
> 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 i
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
6 matches
Mail list logo
