git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: "Catalin Marinas" <catalin.marinas@gmail.com>
Cc: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base
Date: Wed, 13 Dec 2006 14:26:16 -0800	[thread overview]
Message-ID: <7vhcvze8l3.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <b0943d9e0612131401s6cde6d0du5e3c6d2e34bfbbb2@mail.gmail.com> (Catalin Marinas's message of "Wed, 13 Dec 2006 22:01:21 +0000")

"Catalin Marinas" <catalin.marinas@gmail.com> writes:

> On 13/12/06, Junio C Hamano <junkio@cox.net> wrote:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
> What is this new xdl_merge()? Is it a better replacement for diff3? In
> this situation diff3 would actually show two confict parts, each of
> them being the full file, with an empty ancestor.

The calls to xdl_merge() from merge-recursive replace
invocations to external "merge" from RCS suite.

An older merge-recursive had a bug (as you noticed and adjusted
StGIT with the commit 8d41555) in that it did not leave anything
in the working tree in add/add situation, while merge-resolve
would have left its best attempt of ancestor-less two file merge
(which is not necessarily the straight diff3 "no common section,
full copies from both" result).  The change in question corrects
that problem and merge-recursive would create a file in the
working tree just like merge-resolve would.

You were CC'ed just in case this change in behaviour might
interact with the abovementioned change in StGIT, but as you say
the change would not break StGIT, we would all be happy ;-).

  reply	other threads:[~2006-12-13 22:26 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-07 10:17 [PATCH 1/1] Make sure the empty tree exists when needed in merge-recursive Shawn O. Pearce
2006-12-09 23:55 ` [PATCH 1/3] diff_tree_sha1(): avoid rereading trees if possible Johannes Schindelin
2006-12-10  1:47   ` Junio C Hamano
2006-12-10 22:49     ` Johannes Schindelin
2006-12-09 23:56 ` [PATCH 2/3] merge-recursive: make empty tree a known object Johannes Schindelin
2006-12-10 18:37   ` Linus Torvalds
2006-12-10 21:21     ` Junio C Hamano
2006-12-10 21:31       ` Linus Torvalds
2006-12-10 22:33         ` Junio C Hamano
2006-12-10 22:54           ` Linus Torvalds
2006-12-10 22:28       ` Junio C Hamano
2006-12-10 23:16         ` Johannes Schindelin
2006-12-09 23:56 ` [PATCH 3/3] add test case for recursive merge Johannes Schindelin
2006-12-10  0:18   ` Johannes Schindelin
2006-12-10  3:10     ` Junio C Hamano
2006-12-10 22:51       ` Johannes Schindelin
2006-12-12 22:49       ` [PATCH] t6024: fix timing problem Johannes Schindelin
2006-12-12 23:23         ` Junio C Hamano
2006-12-12 23:59           ` Johannes Schindelin
2006-12-13  3:05           ` [PATCH] merge-recursive: add/add really is modify/modify with an empty base Johannes Schindelin
2006-12-13  6:33             ` Junio C Hamano
2006-12-13 11:46               ` StGit repo & gitweb, was " Johannes Schindelin
2006-12-13 11:56                 ` Jakub Narebski
2006-12-13 22:09                 ` Catalin Marinas
2006-12-13 23:06                   ` Robin Rosenberg
2006-12-13 23:50                   ` Johannes Schindelin
2006-12-13 23:57                     ` Jakub Narebski
2006-12-19 18:50                 ` Petr Baudis
2006-12-19 19:39                   ` Jakub Narebski
2006-12-13 22:01               ` Catalin Marinas
2006-12-13 22:26                 ` Junio C Hamano [this message]
2006-12-13 23:48                 ` Johannes Schindelin
2006-12-14 11:31                   ` Catalin Marinas
2006-12-14 11:41                     ` Shawn Pearce
2006-12-14 12:00                     ` Shawn Pearce
2006-12-14 13:44                     ` Johannes Schindelin
2006-12-14 14:15                       ` Catalin Marinas

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vhcvze8l3.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=catalin.marinas@gmail.com \
    --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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).