Re: [RFC 1/3] wt-status: Make conflict hint message more consistent with other hints

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [RFC 1/3] wt-status: Make conflict hint message more consistent with other hints

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:00:00

Andrew Wong [off-list ref] writes:
quoted hunk
Signed-off-by: Andrew Wong <redacted>
---
 wt-status.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/wt-status.c b/wt-status.c
index 4e55810..6e1ad7d 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -899,7 +899,7 @@ static void show_merge_in_progress(struct wt_status *s,
 		status_printf_ln(s, color, _("You have unmerged paths."));
 		if (s->hints)
 			status_printf_ln(s, color,
-				_("  (fix conflicts and run \"git commit\")"));
+				_("  (fix conflicts, and use \"git commit\" to conclude the merge)"));
 	} else {
 		status_printf_ln(s, color,
 			_("All conflicts fixed but you are still merging."));
I see that you are trying to match the phrasing used in the other
side of this if/else (which is outside the context of the posted
patch).  Over there we say "... to conclude merge" while the new
text says "... to conclude THE merge".  Don't we want to match them?

For those who did not look beyond the context of the patch text, as
I had to look these up to convince myself that the proposed change
is a good one.  This function is only called when we see MERGE_HEAD,
so "unmerged" here can come only from a failed merge, not other
mergy operations like am, cherry-pick, revert, etc. and telling the
user that 'commit' will conclude the merge will not be misleading
(unless you count "'git commit' will conclude a conflicted 'git pull'"
as misleading, and I of course do not).

Re: [RFC 1/3] wt-status: Make conflict hint message more consistent with other hints

From: Andrew Wong <hidden>
Date: 2016-06-15 23:00:00

On Wed, Feb 26, 2014 at 3:37 PM, Junio C Hamano [off-list ref] wrote:
I see that you are trying to match the phrasing used in the other
side of this if/else (which is outside the context of the posted
patch).  Over there we say "... to conclude merge" while the new
text says "... to conclude THE merge".  Don't we want to match them?
Ah, good catch. My mind just read it as "conclude THE merge", even
though the word wasn't there. Let's add the "the" in. :)
For those who did not look beyond the context of the patch text, as
I had to look these up to convince myself that the proposed change
is a good one.  This function is only called when we see MERGE_HEAD,
so "unmerged" here can come only from a failed merge, not other
mergy operations like am, cherry-pick, revert, etc. and telling the
user that 'commit' will conclude the merge will not be misleading
(unless you count "'git commit' will conclude a conflicted 'git pull'"
as misleading, and I of course do not).
I'll update the commit message to explain that I'm match the other
side of the if/else.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help