git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH 1/3] t3030: fix accidental success in symlink rename

From
Jeff King <peff@peff.net>
Date
Mar 25, 2011, 16:03 UTC
Message-ID
<20110325160326.GA26635@sigill.intra.peff.net>
In-Reply-To
<20110325160013.GA25851@sigill.intra.peff.net>

In this test, we have merge two branches. On one branch, we renamed "a" to "e". On the other, we renamed "a" to "e" and then added a symlink pointing at "a" pointing to "e".

The results for the test indicate that the merge should succeed, but also that "a" should no longer exist. Since both sides renamed "a" to the same destination, we will end up comparing those destinations for content.

But what about what's left? One side (the rename only), replaced "a" with nothing. The other side replaced it with a symlink. The common base must also be nothing, because any "a" before this was meaningless (it was totally unrelated content that ended up getting renamed).

The only sensible resolution is to keep the symlink. The rename-only side didn't touch the content versus the common base, and the other side added content. The 3-way merge dictates that we take the side with a change.

And this gives the overall merge an intuitive result. One side made one change (a rename), and the other side made two changes: an identical rename, and an addition (that just happened to be at the same spot). The end result should contain both changes.

Signed-off-by: Jeff King <peff@peff.net>
---
Ken, I'm cc'ing you as the test in question is yours. The
context is that I want to turn on break detection in
merge-recursive, but doing so makes your test fail.
 t/t3030-merge-recursive.sh |    7 +++++--
 1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh
index 34794f8..e686f04 100755
--- a/t/t3030-merge-recursive.sh
+++ b/t/t3030-merge-recursive.sh
@@ -267,7 +267,8 @@ test_expect_success 'setup 8' '
 		ln -s e a &&
 		git add a e &&
 		test_tick &&
-		git commit -m "rename a->e, symlink a->e"
+		git commit -m "rename a->e, symlink a->e" &&
+		oln=`printf e | git hash-object --stdin`
 	fi
 '
 
@@ -630,16 +631,18 @@ test_expect_success 'merge-recursive copy vs. rename' '
 
 if test_have_prereq SYMLINKS
 then
-	test_expect_success 'merge-recursive rename vs. rename/symlink' '
+	test_expect_failure 'merge-recursive rename vs. rename/symlink' '
 
 		git checkout -f rename &&
 		git merge rename-ln &&
 		( git ls-tree -r HEAD ; git ls-files -s ) >actual &&
 		(
+			echo "120000 blob $oln	a"
 			echo "100644 blob $o0	b"
 			echo "100644 blob $o0	c"
 			echo "100644 blob $o0	d/e"
 			echo "100644 blob $o0	e"
+			echo "120000 $oln 0	a"
 			echo "100644 $o0 0	b"
 			echo "100644 $o0 0	c"
 			echo "100644 $o0 0	d/e"
-- 
1.7.4.41.g423da.dirty
Previous: Jeff KingNext: Junio C Hamano
Message 6 of 14 in “merge recursive and code movement”
  1. Jay SoffianMar 24, 2011
  2. Jeff KingMar 25, 2011
  3. Jeff KingMar 25, 2011
  4. Jeff KingMar 25, 2011
  5. Jeff KingMar 25, 2011
  6. 1/3 t3030: fix accidental success in symlink renameJeff King, Mar 25, 2011
  7. Junio C HamanoMar 25, 2011
  8. Jeff KingMar 25, 2011
  9. Schalk, KenMar 25, 2011
  10. 2/3 merge: handle renames with replacement contentJeff King, Mar 25, 2011
  11. 3/3 merge: turn on rewrite detectionJeff King, Mar 25, 2011
  12. Jay SoffianMar 25, 2011
  13. Techlive ZhengJul 16, 2012
  14. Jeff KingJul 16, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.