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
next prev 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).