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

[PATCH 2/2] merge-recursive: don't detect renames of empty files

From
Jeff King <peff@peff.net>
Date
Mar 22, 2012, 22:52 UTC
Message-ID
<20120322225223.GB14902@sigill.intra.peff.net>
In-Reply-To
<20120322224651.GA14874@sigill.intra.peff.net>

Merge-recursive detects renames so that if one side modifies "foo" and the other side moves it to "bar", the modification is applied to "bar". However, our rename detection is based on content analysis, it can be wrong (i.e., two files were not intended as a rename, but just happen to have the same or similar content).

This is quite rare if the files actually contain content, since two unrelated files are unlikely to have exactly the same content. However, empty files present a problem, in that there is nothing to analyze. An uninteresting placeholder file with zero bytes may or may not be related to a placeholder file with another name.

The result is that adding content to an empty file may cause confusion if the other side of a merge removed it; your content may end up in another random placeholder file that was added.

Let's err on the side of caution and not consider empty files as renames. This will cause a modify/delete conflict on the merge, which will let the user sort it out themselves.

Signed-off-by: Jeff King <peff@peff.net>
---
 merge-recursive.c       |    1 +
 t/t6022-merge-rename.sh |   16 ++++++++++++++++
 2 files changed, 17 insertions(+)
diff --git a/merge-recursive.c b/merge-recursive.c
index 318d32e..0fb1743 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -485,6 +485,7 @@ static struct string_list *get_renames(struct merge_options *o,
 	renames = xcalloc(1, sizeof(struct string_list));
 	diff_setup(&opts);
 	DIFF_OPT_SET(&opts, RECURSIVE);
+	DIFF_OPT_CLR(&opts, RENAME_EMPTY);
 	opts.detect_rename = DIFF_DETECT_RENAME;
 	opts.rename_limit = o->merge_rename_limit >= 0 ? o->merge_rename_limit :
 			    o->diff_rename_limit >= 0 ? o->diff_rename_limit :
diff --git a/t/t6022-merge-rename.sh b/t/t6022-merge-rename.sh
index 9d8584e..1104249 100755
--- a/t/t6022-merge-rename.sh
+++ b/t/t6022-merge-rename.sh
@@ -884,4 +884,20 @@ test_expect_success 'no spurious "refusing to lose untracked" message' '
 	! grep "refusing to lose untracked file" errors.txt
 '
 
+test_expect_success 'do not follow renames for empty files' '
+	git checkout -f -b empty-base &&
+	>empty1 &&
+	git add empty1 &&
+	git commit -m base &&
+	echo content >empty1 &&
+	git add empty1 &&
+	git commit -m fill &&
+	git checkout -b empty-topic HEAD^ &&
+	git mv empty1 empty2 &&
+	git commit -m rename &&
+	test_must_fail git merge empty-base &&
+	>expect &&
+	test_cmp expect empty2
+'
+
 test_done
-- 
1.7.10.rc0.9.gdcbe9
Previous: Jeff KingNext: Junio C Hamano
Message 22 of 25 in “Strange effect merging empty file”
  1. Ralf NyrenMar 21, 2012
  2. Zbigniew Jędrzejewski-SzmekMar 21, 2012
  3. Junio C HamanoMar 21, 2012
  4. Randal L. SchwartzMar 22, 2012
  5. Ralf NyrenMar 22, 2012
  6. Zbigniew Jędrzejewski-SzmekMar 22, 2012
  7. Jeff KingMar 22, 2012
  8. Junio C HamanoMar 22, 2012
  9. Jeff KingMar 22, 2012
  10. Jeff KingMar 22, 2012
  11. Jeff KingMar 22, 2012
  12. 1/3 drop casts from users EMPTY_TREE_SHA1_BINJeff King, Mar 22, 2012
  13. 2/3 make is_empty_blob_sha1 available everywhereJeff King, Mar 22, 2012
  14. 3/3 merge-recursive: don't detect renames from empty filesJeff King, Mar 22, 2012
  15. Jonathan NiederMar 22, 2012
  16. Jeff KingMar 22, 2012
  17. Junio C HamanoMar 22, 2012
  18. Jeff KingMar 22, 2012
  19. Junio C HamanoMar 22, 2012
  20. 0/2 merging renames of empty filesJeff King, Mar 22, 2012
  21. 1/2 teach diffcore-rename to optionally ignore empty contentJeff King, Mar 22, 2012
  22. 2/2 merge-recursive: don't detect renames of empty filesJeff King, Mar 22, 2012
  23. Junio C HamanoMar 22, 2012
  24. Jeff KingMar 23, 2012
  25. Junio C HamanoMar 23, 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.