From: Charles Bailey <charles@hashpling.org>
To: David Aguilar <davvid@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
John Keeping <john@keeping.me.uk>,
Git Mailing List <git@vger.kernel.org>,
Theodore Ts'o <tytso@mit.edu>
Subject: Re: [RFC PATCH 2/3] mergetools/kdiff3: allow opting-out of auto-merges
Date: Fri, 10 May 2013 06:41:30 +0100 [thread overview]
Message-ID: <20130510054130.GA29215@hashpling.org> (raw)
In-Reply-To: <CAJDDKr4S6=U1d1fWixaiAzf46KLBDNsi85fgvXy0Uu_aRJyoyw@mail.gmail.com>
On Thu, May 09, 2013 at 03:17:30PM -0700, David Aguilar wrote:
> Generally, "mergetool.<tool>.cmd" is not general enough since we've
> always special cased the base vs. no-base code paths and we run
> different commands depending on whether a base is available.
Then this is a deficiency of the ".cmd" mechanism which should provide
an "if all else fails" way to do things, even if ugly. We could simply
add a BASELESS variable to the eval environment of the custom command.
(Do we always create an empty file for $BASE, now?)
> We could drop --auto altogether, which maybe is a better course of
> action since it makes the behavior predictable and un-surprising, but
> I do not know if anyone has come to rely on kdiff3's "auto-merge"
> feature (hence the extended Cc: list).
I disagree, I think that a mergetool should be allowed to be as
helpful as possible and if it can resolve the merge unaided then this
is no bad thing. I've worked with a number of people who were very
happy with the current kdiff3 behaviour. Nothing prevents you from
verifying the merge and fixing it up if it wasn't done perfectly by
the tool, although I haven't ever encountered this with git+kdiff3.
Charles.
next prev parent reply other threads:[~2013-05-10 5:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-09 9:13 [PATCH 1/3] mergetools/kdiff3: do not use --auto when diffing David Aguilar
2013-05-09 9:13 ` [RFC PATCH 2/3] mergetools/kdiff3: allow opting-out of auto-merges David Aguilar
2013-05-09 9:13 ` [RFC PATCH 3/3] Makefile: avoid deprecation warnings on OS X 10.8 David Aguilar
2013-05-09 15:14 ` John Keeping
2013-05-09 23:21 ` David Aguilar
2013-05-09 16:10 ` [RFC PATCH 2/3] mergetools/kdiff3: allow opting-out of auto-merges Junio C Hamano
2013-05-09 17:23 ` John Keeping
2013-05-09 19:15 ` Junio C Hamano
2013-05-09 22:17 ` David Aguilar
2013-05-10 5:41 ` Charles Bailey [this message]
2013-05-10 18:40 ` David Aguilar
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=20130510054130.GA29215@hashpling.org \
--to=charles@hashpling.org \
--cc=davvid@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=john@keeping.me.uk \
--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.