All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Charles Bailey <charles@hashpling.org>
Cc: git@vger.kernel.org
Subject: Re: [RFC/PATCH] Teach git mergetool to use custom commands defined at config time
Date: Sat, 16 Feb 2008 13:11:59 -0800 (PST)	[thread overview]
Message-ID: <m3hcg8bo9f.fsf@localhost.localdomain> (raw)
In-Reply-To: <20080216185349.GA29177@hashpling.org>

Charles Bailey <charles@hashpling.org> writes:

> Currently git mergetool is restricted to a set of commands defined
> in the script. You can subvert the mergetool.<tool>.path to force
> git mergetool to use a different command, but if you have a command
> whose invocation syntax does not match one of the current tools then
> you would have to write a wrapper script for it.
> 
> This patch adds three git config variable patterns which allow a more
> flexible choice of merge tool.

[...]

> It follows filter-branch's 'eval a user shell snippet' philosophy to
> provide the flexibility and here in lies an ugliness. It exposes
> git-mergetool.sh's private variables to the user script. The variables
> are BASE, REMOTE, LOCAL and path.

Another solution would be to use StGit merger / i2merge / i3merge
format, similar to git-for-each-ref format, namely to expand
%(branch1), %(branch2), %(ancestor), %(output) (well, StGit uses
for some reason %(ancestor)s etc.; git-for-each-ref doesn't).

Although for this would be better if git-mergetool was rewritten
in C, in Perl (or even in Python).

-- 
Jakub Narebski
Poland
ShadeHawk on #git

  parent reply	other threads:[~2008-02-16 21:12 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 [this message]
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
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=m3hcg8bo9f.fsf@localhost.localdomain \
    --to=jnareb@gmail.com \
    --cc=charles@hashpling.org \
    --cc=git@vger.kernel.org \
    /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.