From: Junio C Hamano <gitster@pobox.com>
To: Jason Wenger <jcwenger@gmail.com>
Cc: David Aguilar <davvid@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH v3] mergetool: Provide an empty file when needed
Date: Fri, 20 Jan 2012 10:28:25 -0800 [thread overview]
Message-ID: <7vbopyfcty.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CAM6z=4-HfRAjJjnYqfoiYsYjiZJSsbkCaW-VtLWvoeFM0xsB9g@mail.gmail.com> (Jason Wenger's message of "Fri, 20 Jan 2012 08:03:01 -0600")
Jason Wenger <jcwenger@gmail.com> writes:
> On Fri, Jan 20, 2012 at 01:53, David Aguilar <davvid@gmail.com> wrote:
>> On Thu, Jan 19, 2012 at 11:47 PM, David Aguilar <davvid@gmail.com> wrote:
>>> Some merge tools cannot cope when $LOCAL, $BASE, or $REMOTE
>>> are missing. $BASE can be missing when two branches
>>> independently add the same filename. $LOCAL and $REMOTE
>>> can be missing when a delete/modify conflict occurs.
>>>
>>> Provide an empty file to make these tools happy.
>
> This is cleaner, yes -- but is this extra processing on $LOCAL and
> $REMOTE necessary? Git mergetool doesn't actually call an external
> mergetool during del/mod conflicts -- instead it goes into an
> alternate processing and prompts the user interactively whether to
> take the deleted or modified file. Can these changes be reached?
> (command line option I'm not aware of?)
Thanks for a careful reading. I did not read outside the context of the
patch so I didn't know if we had special cases for del/mod.
A bigger question is if the del/mod codepaths are negatively affected by
the presense of these superfluous empty $LOCAL/$REMOTE files. If they are,
this change will _break_ things. If they are not, I think the change would
be OK.
Another small worry is that this could potentially negatively affect some
merge tools that are sufficiently clueful, if it can give different and
better results for a true two-way-merge than a simulated two-way-merge
this patch feeds them by using a three-way-merge with an empty file as a
base.
next prev parent reply other threads:[~2012-01-20 18:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-18 23:05 Interesting behavior in git mergetool with no BASE revision Jason Wenger
2012-01-20 6:43 ` David Aguilar
2012-01-20 6:46 ` [PATCH] mergetool: Provide an empty file when no base exists David Aguilar
2012-01-20 6:57 ` David Aguilar
2012-01-20 7:00 ` Junio C Hamano
2012-01-20 7:07 ` David Aguilar
2012-01-20 7:10 ` David Aguilar
2012-01-20 7:22 ` Junio C Hamano
2012-01-20 7:26 ` David Aguilar
2012-01-20 7:37 ` Junio C Hamano
2012-01-20 7:39 ` Junio C Hamano
2012-01-20 7:47 ` [PATCH v3] mergetool: Provide an empty file when needed David Aguilar
2012-01-20 7:53 ` David Aguilar
2012-01-20 14:03 ` Jason Wenger
2012-01-20 18:28 ` Junio C Hamano [this message]
2012-01-20 7:37 ` David Aguilar
2012-01-20 7:14 ` [PATCH v2] mergetool: Provide an empty file when no base exists 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=7vbopyfcty.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=davvid@gmail.com \
--cc=git@vger.kernel.org \
--cc=jcwenger@gmail.com \
/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).