From: Charles Bailey <charles@hashpling.org>
To: Theodore Tso <tytso@MIT.EDU>
Cc: Steffen Prohaska <prohaska@zib.de>,
Junio C Hamano <gitster@pobox.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [RFC/PATCH] Teach git mergetool to use custom commands defined at config time
Date: Sun, 17 Feb 2008 23:28:58 +0000 [thread overview]
Message-ID: <20080217232858.GA6249@hashpling.org> (raw)
In-Reply-To: <20080217214942.GJ8905@mit.edu>
On Sun, Feb 17, 2008 at 04:49:42PM -0500, Theodore Tso wrote:
> I think it *would* be better to use %(foo) extrapolation that
> environment variables, so that it's not required for users to write
> shell scripts unless absolutely necessary.
I understand that %(foo) is neater, but this would make the shell
implementation significantly more complex, and also potentially less
flexible (e.g. if you needed to do the opendiff style |cat trick or
some similar shell trickery).
The reason that I first posted a patch for a different config variable
for baseless merges was because I was that a significant number of
merge tools have significantly different syntaxes for two and three
way merges and I thought that it might be easier for users to do
something like:
git config mergetool.mymerge.cmd 'mytool --3way "$BASE" "$LOCAL" \
"$REMOTE" "$MERGED"'
git config mergetool.mymerge.cmdNoBase 'mytool --2way "$LOCAL" \
"$REMOTE" "$MERGED"'
than it would be to do something like (totally untested):
git config mergetool.mymerge.cmd 'if test -f "$BASE"; then;\
mytool --3way "$BASE" "$LOCAL" "$REMOTE" "$MERGED"; else; \
mytool --2way "$LOCAL" "$REMOTE" "$MERGED"; fi'
So in the former case you are still using shell syntax, but a simple
subset of shell should suffice for most needs. The later case
requires more wizardry.
> When we get around to rewriting git-mergetool in C, it might make
> sense to put the tool support in the various shell scripts that are
> installed in the git helper binary directory (i.e.,
> git-mergetool-kdiff3, git-mergetool-meld, etc.) That would make it
> easier for users to create new shell scripts to support new tools if
> necessary.
>
> - Ted
This makes sense to me, although I have to say that I'm not really
sure I see the value of turning git-mergetool into C. It seems to
make a lot of sense as a shell helper, but is it a general principle
that all of git's commands should eventually be converted to C?
Charles.
next prev parent reply other threads:[~2008-02-17 23:30 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
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 [this message]
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=20080217232858.GA6249@hashpling.org \
--to=charles@hashpling.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=prohaska@zib.de \
--cc=tytso@MIT.EDU \
/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.