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

[PATCH 11/12] rerere: never renormalize

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Aug 5, 2010, 11:30 UTC
Message-ID
<20100805113026.GM13779@burratino>
In-Reply-To
<20100805110822.GB13779@burratino>

plain rerere performs three tasks; let us consider how the new merge.renormalize option should apply to each.

After an unsuccessful merge, rerere records conflict hunks from the work tree under .git/rr-cache. If the merge was performed with merge.renormalize enabled, both sides of the conflict hunk use the current work tree’s end-of-line and smudge rules; there is not really much of a choice.

After a successful manual resolution, rerere records the postimage. Here, also, the file will be in the current work tree’s canonical format and there is not much to do about it.

When encountering that conflict again, merge looks up the preimage and postimage using the conflict hunk as a key and runs a three-way merge to apply that resolution to the work tree. Since the conflict hunk used the current work tree’s canonical format, chances are the version in the work tree, the preimage, and the postimage will, too. In fact using the merge.renormalize machinery is exactly the wrong thing to do, since its result has been run through convert_to_git and therefore is not suitable for writing to the work tree.

The only affected caller is "git merge".
NEEDSWORK: lacks test
Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
 rerere.c |   11 +++++------
 1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/rerere.c b/rerere.c
index 9dd4c7e..e40af0d 100644
--- a/rerere.c
+++ b/rerere.c
@@ -365,7 +365,7 @@ static int find_conflict(struct string_list *conflict)
 	return 0;
 }
 
-static int merge(const char *name, int renormalize, const char *path)
+static int merge(const char *name, const char *path)
 {
 	int ret;
 	mmfile_t cur = {NULL, 0}, base = {NULL, 0}, other = {NULL, 0};
@@ -380,8 +380,7 @@ static int merge(const char *name, int renormalize, const char *path)
 		ret = 1;
 		goto out;
 	}
-	ret = ll_merge(&result, path, &base, NULL, &cur, "", &other, "",
-			renormalize ? LL_OPT_RENORMALIZE : 0);
+	ret = ll_merge(&result, path, &base, NULL, &cur, "", &other, "", 0);
 	if (!ret) {
 		FILE *f = fopen(path, "w");
 		if (!f)
@@ -429,7 +428,7 @@ static int update_paths(struct string_list *update)
 	return status;
 }
 
-static int do_plain_rerere(struct string_list *rr, int fd, int renormalize)
+static int do_plain_rerere(struct string_list *rr, int fd)
 {
 	struct string_list conflict = { NULL, 0, 0, 1 };
 	struct string_list update = { NULL, 0, 0, 1 };
@@ -474,7 +473,7 @@ static int do_plain_rerere(struct string_list *rr, int fd, int renormalize)
 		const char *name = (const char *)rr->items[i].util;
 
 		if (has_rerere_resolution(name)) {
-			if (!merge(name, renormalize, path)) {
+			if (!merge(name, path)) {
 				if (rerere_autoupdate)
 					string_list_insert(path, &update);
 				fprintf(stderr,
@@ -558,7 +557,7 @@ int rerere(int flags)
 	fd = setup_rerere(&merge_rr, flags);
 	if (fd < 0)
 		return 0;
-	return do_plain_rerere(&merge_rr, fd, merge_renormalize);
+	return do_plain_rerere(&merge_rr, fd);
 }
 
 static int rerere_forget_one_path(const char *path, struct string_list *rr)
-- 
1.7.2.1.544.ga752d.dirty
Previous: Jonathan NiederNext: Jonathan Nieder
Message 31 of 35 in “Merge renormalization, config renamed”
  1. 0/3 Merge renormalization, config renamedEyvind Bernhardsen, Jul 2, 2010
  2. 1/3 Avoid conflicts when merging branches with mixed normalizationEyvind Bernhardsen, Jul 2, 2010
  3. 2/3 Try normalizing files to avoid delete/modify conflicts when mergingEyvind Bernhardsen, Jul 2, 2010
  4. 3/3 Don't expand CRLFs when normalizing text during mergeEyvind Bernhardsen, Jul 2, 2010
  5. Junio C HamanoJul 2, 2010
  6. 0/6 merge -XrenormalizeJonathan Nieder, Aug 4, 2010
  7. 1/6 merge-trees: push choice to renormalize away from low levelJonathan Nieder, Aug 4, 2010
  8. 2/6 merge-trees: let caller decide whether to renormalizeJonathan Nieder, Aug 4, 2010
  9. 3/6 ll-merge: let caller decide whether to renormalizeJonathan Nieder, Aug 4, 2010
  10. Junio C HamanoAug 4, 2010
  11. 4/6 rerere: migrate to parse-options APIJonathan Nieder, Aug 4, 2010
  12. 5/6 rerere: let caller decide whether to renormalizeJonathan Nieder, Aug 4, 2010
  13. Junio C HamanoAug 4, 2010
  14. 0/12 Re: rerere: let caller decide whether to renormalizeJonathan Nieder, Aug 5, 2010
  15. 01/12 t6038 (merge.renormalize): style nitpicksJonathan Nieder, Aug 5, 2010
  16. Ævar Arnfjörð BjarmasonAug 5, 2010
  17. Jonathan NiederAug 5, 2010
  18. 02/12 t6038 (merge.renormalize): try checkout -m and cherry-pickJonathan Nieder, Aug 5, 2010
  19. 03/12 t6038 (merge.renormalize): check that it can be turned offJonathan Nieder, Aug 5, 2010
  20. 04/12 merge-trees: push choice to renormalize away from low levelJonathan Nieder, Aug 5, 2010
  21. 05/12 merge-trees: let caller decide whether to renormalizeJonathan Nieder, Aug 5, 2010
  22. 06/12 Documentation/technical: document ll_mergeJonathan Nieder, Aug 5, 2010
  23. 07/12 ll-merge: make flag easier to populateJonathan Nieder, Aug 5, 2010
  24. Bert WesargAug 5, 2010
  25. Jonathan NiederAug 5, 2010
  26. Bert WesargAug 5, 2010
  27. Jonathan NiederAug 5, 2010
  28. 08/12 ll-merge: let caller decide whether to renormalizeJonathan Nieder, Aug 5, 2010
  29. 09/12 t4200 (rerere): modernize styleJonathan Nieder, Aug 5, 2010
  30. 10/12 rerere: migrate to parse-options APIJonathan Nieder, Aug 5, 2010
  31. 11/12 rerere: never renormalizeJonathan Nieder, Aug 5, 2010
  32. 12/12 merge-recursive --renormalizeJonathan Nieder, Aug 5, 2010
  33. Eyvind BernhardsenAug 5, 2010
  34. 6/6 merge-recursive: add -Xrenormalize optionJonathan Nieder, Aug 4, 2010
  35. Junio C HamanoAug 4, 2010

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.