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

[PATCH 3/4] merge-recursive: improve auto-merging messages with path collisions

From
Elijah Newren <newren@gmail.com>
Date
Oct 12, 2018, 21:25 UTC
Message-ID
<20181012212551.7689-4-newren@gmail.com>
In-Reply-To
<20181012212551.7689-1-newren@gmail.com>

Each individual file involved in a rename could have also been modified on both sides of history, meaning it may need to have content merges. If two such files are renamed into the same location, then on top of the two natural auto-merging messages we also have to two-way merge the result, giving us messages that look like

  Auto-merging somefile.c (was somecase.c)
  Auto-merging somefile.c (was somefolder.c)
  Auto-merging somefile.c

However, despite the fact that I was the one who put the "(was %s)" portions into the messages (and just a few months ago), I was still initially confused when running into a rename/rename(2to1) case and wondered if somefile.c had been merged three times. Update this to instead be:

  Auto-merging version of somefile.c from somecase.c
  Auto-merging version of somefile.c from someportfolio.c
  Auto-merging somefile.c

This is an admittedly long set of messages for a single path, but you only get all three messages when dealing with the rare case of a rename/rename(2to1) conflict where both sides of both original files were also modified, in conflicting ways.

Signed-off-by: Elijah Newren <newren@gmail.com>
---
 merge-recursive.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 2452788d28..33cd9ee81f 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1679,8 +1679,8 @@ static int handle_rename_rename_2to1(struct merge_options *o,
 	remove_file(o, 1, a->path, o->call_depth || would_lose_untracked(a->path));
 	remove_file(o, 1, b->path, o->call_depth || would_lose_untracked(b->path));
 
-	path_side_1_desc = xstrfmt("%s (was %s)", path, a->path);
-	path_side_2_desc = xstrfmt("%s (was %s)", path, b->path);
+	path_side_1_desc = xstrfmt("version of %s from %s", path, a->path);
+	path_side_2_desc = xstrfmt("version of %s from %s", path, b->path);
 	if (merge_mode_and_contents(o, a, c1, &ci->ren1_other, path_side_1_desc,
 				    o->branch1, o->branch2,
 				    o->call_depth * 2, &mfi_c1) ||
-- 
2.19.0.235.g7c386e1068
Previous: Elijah NewrenNext: Junio C Hamano
Message 2 of 15 in “More merge cleanups”
  1. 0/4 More merge cleanupsElijah Newren, Oct 12, 2018
  2. 3/4 merge-recursive: improve auto-merging messages with path collisionsElijah Newren, Oct 12, 2018
  3. Junio C HamanoOct 15, 2018
  4. 4/4 merge-recursive: Avoid showing conflicts with merge branch before HEADElijah Newren, Oct 12, 2018
  5. Junio C HamanoOct 15, 2018
  6. 1/4 t6036: add testcase where virtual merge base contains nested conflictsElijah Newren, Oct 12, 2018
  7. 2/4 merge-recursive: increase marker length with depth of recursionElijah Newren, Oct 12, 2018
  8. Junio C HamanoOct 15, 2018
  9. Elijah NewrenOct 15, 2018
  10. Junio C HamanoOct 16, 2018
  11. Elijah NewrenOct 16, 2018
  12. 0/2 More merge cleanupsElijah Newren, Oct 16, 2018
  13. 1/2 merge-recursive: improve auto-merging messages with path collisionsElijah Newren, Oct 16, 2018
  14. 2/2 merge-recursive: avoid showing conflicts with merge branch before HEADElijah Newren, Oct 16, 2018
  15. Junio C HamanoOct 18, 2018

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.