threads / rfc / 17185

RFC patchZooko's merge testcase

Subject: [RFC PATCH] Zooko's merge testcase

## tl;dr

2 messages between Jan 15, 2009 and Jan 15, 2009. Diffs are folded; open one to read it.

replies: 1people: 2as markdown or json

Miklos Vajna· Jan 15, 2009, 00:53 UTC · lore
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
The original page is here:
https://zooko.com/badmerge/simple.html
IIRC it was Robin who mentioned it on IRC.

I obviously not send this patch for inclusion, but to raise a discussion: if I were a naive user I would think the merge will at least result in a conflict, however actually it just gaves a wrong result.

 t/t7608-merge-zooko.sh |   88 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 88 insertions(+), 0 deletions(-)
 create mode 100755 t/t7608-merge-zooko.sh
Show changes to t/t7608-merge-zooko.sh +88 −0
diff --git a/t/t7608-merge-zooko.sh b/t/t7608-merge-zooko.sh
new file mode 100755
index 0000000..32609c0
--- /dev/null
+++ b/t/t7608-merge-zooko.sh
@@ -0,0 +1,88 @@
+#!/bin/sh
+
+test_description='git merge
+
+Testing merge with the examples of Zooko.'
+
+. ./test-lib.sh
+
+#
+# A - D     \
+#   \ B - C - E
+#
+test_expect_success 'setup' '
+	cat <<EOF >file &&
+A
+B
+C
+D
+E
+EOF
+	git add file &&
+	git commit -m A &&
+	git tag A &&
+	cat <<EOF >file &&
+G
+G
+G
+A
+B
+C
+D
+E
+EOF
+	git add file &&
+	git commit -m B &&
+	git tag B &&
+	cat <<EOF >file &&
+A
+B
+C
+D
+E
+G
+G
+G
+A
+B
+C
+D
+E
+EOF
+	git add file &&
+	git commit -m C &&
+	git tag C &&
+	git reset --hard A &&
+	cat <<EOF >file &&
+A
+B
+X
+D
+E
+EOF
+	git add file &&
+	git commit -m D &&
+	git tag D
+'
+
+test_expect_failure 'merge C' '
+	cat <<EOF >expected &&
+A
+B
+C
+D
+E
+G
+G
+G
+A
+B
+X
+D
+E
+EOF
+	git merge C &&
+	test_cmp expected file
+'
+
+test_done
-- 
1.6.1
Johannes Schindelin· Jan 15, 2009, 03:36 UTC · re: Miklos Vajna · lore

Re: [RFC PATCH] Zooko's merge testcase

Hi,
On Thu, 15 Jan 2009, Miklos Vajna wrote:
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---

I think the idea can be simplified. Given lines A, B, C in the base commit, one branch _prepending_ the same triplet, and the other branch changing the B to a D.

Only this time, nobody has a chance, even Darcs, because from the diff, you would not know if it was prepended or appended.

(Which happens to be the same problem as 3-way merge has with the example you were implementing; only when looking at the detailed history becomes it clear what was done.)

This all just proves again that there can be no perfect merge strategy; you'll always have to verify that the right thing was done.

Ciao, Dscho

← back to recent threads