git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Charles Bailey <charles@hashpling.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/4] Teach git mergetool to use custom commands defined at config time
Date: Sun, 17 Feb 2008 03:08:39 -0800	[thread overview]
Message-ID: <7vmypz262w.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: b63a66ef2a97cd3e791476a74bdb7081bcd57637.1203242325.git.charles@hashpling.org

Charles Bailey <charles@hashpling.org> writes:

> This series of patches are a cleaned and improved version of the
> earlier RFC patch that I sent.

About the organization of the series, I think (note that what I
think does not count as much as what Ted thinks around this
area) it would make much more sense to do 4 first (unless there
is a reason why it behaves differently for existing backends),
then 2 (remove $path everywhere and use $MERGED consistently,
not just where you call out to the custom tool), and then
finally 1.  The general idea is to clean-up first and then add
features on solidified base.

I do not personally see much need for 3, as the custom script
should be able to check the situation and adjust its behaviour
accordingly, and that way you do not have to maintain two
scripts.  I.e. if $BASE does not exist, there is no base, no?

      parent reply	other threads:[~2008-02-17 11:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-17 10:23 [PATCH 1/4] Teach git mergetool to use custom commands defined at config time Charles Bailey
2008-02-17 10:23 ` [PATCH 2/4] Changed the documented variable for mergetool's target file Charles Bailey
2008-02-17 10:24 ` [PATCH 3/4] Allow a different mergetool command to be used for 'no base' merges Charles Bailey
2008-02-17 10:24 ` [PATCH 4/4] Tidy up git mergetool's handling of backup files Charles Bailey
2008-02-17 11:08 ` Junio C Hamano [this message]

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=7vmypz262w.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).