git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Gerrit Pape <pape@smarden.org>
Cc: git@vger.kernel.org, "Rémi Vanicat" <vanicat@debian.org>,
	gitster@pobox.com
Subject: [PATCH] merge-tree: sometimes, d/f conflict is not an issue
Date: Sun, 8 Jul 2007 01:52:06 +0100 (BST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0707080148370.4093@racer.site> (raw)
In-Reply-To: <20070625071819.8091.qmail@5e4088a43a10fd.315fe32.mid.smarden.org>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3427 bytes --]


When a merge has a d/f conflict on a path which was not touched
between the merge base(s) and the remote HEAD, and the index and
HEAD contain the same version for that path (even if empty), it
is not really a conflict.

Noticed by Rémi Vanicat, reported to the Git list by Gerrit Pape.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	The only peculiar result is that you can have an entry at
	stage 0 for one path, and stages 1 and 3 for another path
	where the first path is a prefix.

	This can happen now, when you have deleted a directory
	since the branching point, and put a file in the same place, but
	the other side has changed files in that directory.

	This change is reflected in the change to t3030.

	I have no idea if the change is the best there is, but after
	spending some hours trying to get my head around what is written
	in Documentation/technical/trivial-merge.txt, and what is in
	the function threeway_merge(), and still not understanding most of 
	it, there is not much more that I can do.

	Funny note at the side: when I finally got to Gerrit's email again
	today, gmane said _almost_ that it was 3 weeks, 3 days, 3 hours
	and 3 minutes ago...

 t/t3030-merge-recursive.sh |    2 +-
 t/t3502-cherry-pick.sh     |   31 +++++++++++++++++++++++++++++++
 unpack-trees.c             |   14 ++++++++++++++
 3 files changed, 46 insertions(+), 1 deletions(-)
 create mode 100755 t/t3502-cherry-pick.sh

diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh
index 607f57f..d413af1 100755
--- a/t/t3030-merge-recursive.sh
+++ b/t/t3030-merge-recursive.sh
@@ -450,7 +450,7 @@ test_expect_success 'merge-recursive d/f conflict result' '
 		echo "100644 $o1 0	a"
 		echo "100644 $o0 0	b"
 		echo "100644 $o0 0	c"
-		echo "100644 $o6 2	d"
+		echo "100644 $o6 0	d"
 		echo "100644 $o0 1	d/e"
 		echo "100644 $o1 3	d/e"
 	) >expected &&
diff --git a/t/t3502-cherry-pick.sh b/t/t3502-cherry-pick.sh
new file mode 100755
index 0000000..da3d26e
--- /dev/null
+++ b/t/t3502-cherry-pick.sh
@@ -0,0 +1,31 @@
+#!/bin/sh
+
+test_description='test cherry-pick'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+	echo foo > file &&
+	ln -s dangling link &&
+	git add file link &&
+	test_tick &&
+	git commit -m foo &&
+	git checkout -b branch &&
+	git rm link &&
+	test_tick &&
+	git commit -m "remove link" &&
+	mkdir link &&
+	echo bar > link/file &&
+	git add link/file &&
+	test_tick &&
+	git commit -m "add dir" &&
+	echo bar > file &&
+	git commit -m "change file" file &&
+	git checkout master
+'
+
+test_expect_success 'cherry-pick ignores unrelated dir/symlink conflict' '
+	git cherry-pick branch
+'
+
+test_done
diff --git a/unpack-trees.c b/unpack-trees.c
index cac2411..080b016 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -643,6 +643,20 @@ int threeway_merge(struct cache_entry **stages,
 	index = stages[0];
 	head = stages[o->head_idx];
 
+	/*
+	 * Special case: do not care about a dir/file conflict, when
+	 * the entries have not been touched.
+	 * IOW if the ancestors are identical to the remote, and the
+	 * index is the same as head, just take head.
+	 */
+	if (head && same(index, head)) {
+		for (i = 1; i < o->head_idx; i++)
+			if (!same(stages[i], remote))
+				break;
+		if (i == o->head_idx)
+			return merged_entry(head, index, o);
+	}
+
 	if (head == o->df_conflict_entry) {
 		df_conflict_head = 1;
 		head = NULL;
-- 
1.5.3.rc0.2712.g125b7f


  parent reply	other threads:[~2007-07-08  0:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070405071615.2915.6837.reportbug@acer>
     [not found] ` <20070607074357.27760.qmail@69aef7b888effd.315fe32.mid.smarden.org>
     [not found]   ` <6b8a91420706070252y3fd581a3w427d91e5b982d29d@mail.gmail.com>
2007-06-13  9:16     ` unexpected git-cherry-pick conflict Gerrit Pape
2007-06-13 12:58       ` Johannes Schindelin
2007-06-13 13:43         ` Gerrit Pape
2007-06-13 14:43           ` Johannes Schindelin
2007-06-25  7:18             ` Gerrit Pape
2007-06-25  7:55               ` Johannes Schindelin
2007-07-07 20:58               ` Johannes Schindelin
2007-12-21 10:37                 ` Gerrit Pape
2007-12-22  8:20                   ` Junio C Hamano
2007-07-08  0:52               ` Johannes Schindelin [this message]
2007-07-08  1:31                 ` [PATCH] merge-tree: sometimes, d/f conflict is not an issue Junio C Hamano
2007-07-08  2:00                   ` Johannes Schindelin
2007-07-08  2:18                     ` Johannes Schindelin
2007-07-08  4:35                       ` Johannes Schindelin
2007-07-08  5:50                     ` Junio C Hamano
2007-07-08  6:14                       ` Junio C Hamano
2007-07-08 13:16                         ` Johannes Schindelin
2007-07-08 20:02                           ` Junio C Hamano
2007-07-09 15:06                             ` merge-one-file, was " Johannes Schindelin
2007-07-17 17:13                             ` [PATCH 1/2] merge-recursive: " Johannes Schindelin
2007-08-08 14:39                               ` Gerrit Pape
2007-07-17 17:14                             ` [PATCH 2/2] Add tests for cherry-pick d/f conflict which should be none Johannes Schindelin
2007-07-08 12:53                       ` [PATCH] merge-tree: sometimes, d/f conflict is not an issue Johannes Schindelin

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=Pine.LNX.4.64.0707080148370.4093@racer.site \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pape@smarden.org \
    --cc=vanicat@debian.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).