Re: [PATCH 4/9] merge-ort: mark a few more conflict messages as omittable

2 messages, 2 authors, 2021-12-23 · open the first message on its own page

Re: [PATCH 4/9] merge-ort: mark a few more conflict messages as omittable

From: Junio C Hamano <hidden>
Date: 2021-12-22 00:06:10

"Elijah Newren via GitGitGadget" [off-list ref] writes:
From: Elijah Newren <redacted>

path_msg() has the ability to mark messages as omittable, designed for
remerge-diff where we'll instead be showing conflict messages as diff
headers for a subsequent diff.  While all these messages are very useful
when trying to create a merge initially, early use with the
--remerge-diff feature (the only user of this omittable conflict message
capability), suggests that the particular messages marked in this commit
are just noise when trying to see what changes users made to create a
merge commit.
It is likely because when somebody is looking at the output of
remerge-diff, they are mostly concentrating on the _content_ level
merges and they are not keenly looking for a merge whose result is
deposited at a wrong path.  Since what is shown is something that
has already recorded in the history, we can safely assume that it is
no longer a relevant (or "it is way too late to matter"), I would
say, to show these messages about "file location".
quoted hunk
Signed-off-by: Elijah Newren <redacted>
---
 merge-ort.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/merge-ort.c b/merge-ort.c
index a18f47e23c5..fe27870e73e 100644
--- a/merge-ort.c
+++ b/merge-ort.c
@@ -2420,7 +2420,7 @@ static void apply_directory_rename_modifications(struct merge_options *opt,
 		 */
 		ci->path_conflict = 1;
 		if (pair->status == 'A')
-			path_msg(opt, new_path, 0,
+			path_msg(opt, new_path, 1,
 				 _("CONFLICT (file location): %s added in %s "
 				   "inside a directory that was renamed in %s, "
 				   "suggesting it should perhaps be moved to "
@@ -2428,7 +2428,7 @@ static void apply_directory_rename_modifications(struct merge_options *opt,
 				 old_path, branch_with_new_path,
 				 branch_with_dir_rename, new_path);
 		else
-			path_msg(opt, new_path, 0,
+			path_msg(opt, new_path, 1,
 				 _("CONFLICT (file location): %s renamed to %s "
 				   "in %s, inside a directory that was renamed "
 				   "in %s, suggesting it should perhaps be "
@@ -3825,7 +3825,7 @@ static void process_entry(struct merge_options *opt,
 				reason = _("add/add");
 			if (S_ISGITLINK(merged_file.mode))
 				reason = _("submodule");
-			path_msg(opt, path, 0,
+			path_msg(opt, path, 1,
 				 _("CONFLICT (%s): Merge conflict in %s"),
 				 reason, path);
I am not as sure about this one as the other two, though.  I guess
in the context of remerge-diff, resolving the add/add conflict into
the same file is also something that happened long time ago and
these messages are too late to matter the same way as the other two.

OK.

Re: [PATCH 4/9] merge-ort: mark a few more conflict messages as omittable

From: Elijah Newren <hidden>
Date: 2021-12-23 18:38:35

On Tue, Dec 21, 2021 at 4:06 PM Junio C Hamano [off-list ref] wrote:
"Elijah Newren via GitGitGadget" [off-list ref] writes:
quoted
From: Elijah Newren <redacted>

path_msg() has the ability to mark messages as omittable, designed for
remerge-diff where we'll instead be showing conflict messages as diff
headers for a subsequent diff.  While all these messages are very useful
when trying to create a merge initially, early use with the
--remerge-diff feature (the only user of this omittable conflict message
capability), suggests that the particular messages marked in this commit
are just noise when trying to see what changes users made to create a
merge commit.
It is likely because when somebody is looking at the output of
remerge-diff, they are mostly concentrating on the _content_ level
merges and they are not keenly looking for a merge whose result is
deposited at a wrong path.  Since what is shown is something that
has already recorded in the history, we can safely assume that it is
no longer a relevant (or "it is way too late to matter"), I would
say, to show these messages about "file location".
quoted
Signed-off-by: Elijah Newren <redacted>
---
 merge-ort.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/merge-ort.c b/merge-ort.c
index a18f47e23c5..fe27870e73e 100644
--- a/merge-ort.c
+++ b/merge-ort.c
@@ -2420,7 +2420,7 @@ static void apply_directory_rename_modifications(struct merge_options *opt,
               */
              ci->path_conflict = 1;
              if (pair->status == 'A')
-                     path_msg(opt, new_path, 0,
+                     path_msg(opt, new_path, 1,
                               _("CONFLICT (file location): %s added in %s "
                                 "inside a directory that was renamed in %s, "
                                 "suggesting it should perhaps be moved to "
@@ -2428,7 +2428,7 @@ static void apply_directory_rename_modifications(struct merge_options *opt,
                               old_path, branch_with_new_path,
                               branch_with_dir_rename, new_path);
              else
-                     path_msg(opt, new_path, 0,
+                     path_msg(opt, new_path, 1,
                               _("CONFLICT (file location): %s renamed to %s "
                                 "in %s, inside a directory that was renamed "
                                 "in %s, suggesting it should perhaps be "
@@ -3825,7 +3825,7 @@ static void process_entry(struct merge_options *opt,
                              reason = _("add/add");
                      if (S_ISGITLINK(merged_file.mode))
                              reason = _("submodule");
-                     path_msg(opt, path, 0,
+                     path_msg(opt, path, 1,
                               _("CONFLICT (%s): Merge conflict in %s"),
                               reason, path);
I am not as sure about this one as the other two, though.  I guess
in the context of remerge-diff, resolving the add/add conflict into
the same file is also something that happened long time ago and
these messages are too late to matter the same way as the other two.
Yeah, I'm not so sure about it either, and my notes are long, long
gone.  I think I'll pull this one out, and we can always tweak it
later if needed.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help