From: Charles Bailey <charles@hashpling.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Steffen Prohaska <prohaska@zib.de>, git@vger.kernel.org
Subject: Re: [RFC/PATCH] Teach git mergetool to use custom commands defined at config time
Date: Sun, 17 Feb 2008 00:56:20 +0000 [thread overview]
Message-ID: <20080217005620.GB504@hashpling.org> (raw)
In-Reply-To: <alpine.LSU.1.00.0802170045210.30505@racer.site>
On Sun, Feb 17, 2008 at 12:46:15AM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 17 Feb 2008, Charles Bailey wrote:
>
> > On Sat, Feb 16, 2008 at 11:37:31PM +0100, Steffen Prohaska wrote:
> >
> > > Why not just add the tools you have in mind to git mergetool? If
> > > everyone did that eventually we would have direct support for a rather
> > > long list of tools. This would be the easiest solution for the end
> > > user: He could just choose the preferred tool and use it. The
> > > invocation of each merge tool would be coded in mergetool. The exact
> > > command line could be fine tuned and would be reviewed by other git
> > > developers.
> > >
> >
> > I have to disagree with this approach.
>
> So you'd rather have the end users do the same work for the same tool over
> and over again?
>
I'm sorry, I should have made myself clearer. I disagree that the
approach of adding new tool support to the source code as and when they
are encountered is optimal. I believe that it is preferable to have a
solution that allows users to configure, rather then code, support for
their own tools that do not to have native support.
I do not disagree that there is benefit to having a wide range of
tools that are supported natively.
I thought I made a reasonable argument for this in the rest of my
email that you took the headline from, but evidently I came across as
muddled.
Charles.
next prev parent reply other threads:[~2008-02-17 0:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-16 18:53 [RFC/PATCH] Teach git mergetool to use custom commands defined at config time Charles Bailey
2008-02-16 20:04 ` Junio C Hamano
2008-02-16 20:20 ` Charles Bailey
2008-02-16 21:11 ` Jakub Narebski
2008-02-16 22:37 ` Steffen Prohaska
2008-02-17 0:20 ` Charles Bailey
2008-02-17 0:46 ` Johannes Schindelin
2008-02-17 0:56 ` Charles Bailey [this message]
2008-02-17 1:15 ` Junio C Hamano
2008-02-17 7:59 ` Steffen Prohaska
2008-02-17 10:15 ` Charles Bailey
2008-02-17 21:49 ` Theodore Tso
2008-02-17 23:28 ` Charles Bailey
2008-02-17 23:41 ` Charles Bailey
2008-02-18 0:30 ` Junio C Hamano
2008-02-18 8:14 ` Charles Bailey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080217005620.GB504@hashpling.org \
--to=charles@hashpling.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=prohaska@zib.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.