Junio C Hamano <gitster@xxxxxxxxx> a écrit :
@@ -728,6 +729,167 @@ static void wt_status_print_tracking(struct wt_status *s)... +static void show_am_in_progress(struct wt_status *s, + struct wt_status_state *state, + const char *color) +{ + status_printf_ln(s, color, + _("You are in the middle of an am session.")); + if (state->am_empty_patch) + status_printf_ln(s, color, + _("The current patch is empty.")); + if (advice_status_hints) { + status_printf_ln(s, color, + _(" (use \"git am --abort\" to restore the original branch)")); + status_printf_ln(s, color, + _(" (use \"git am --skip\" to skip this patch)")); + if (!state->am_empty_patch) + status_printf_ln(s, color, + _(" (when you have fixed this problem run \"git am --resolved\")")); + } + wt_status_print_trailer(s); +}Perhaps s/fixed this problem/resolved conflicts/ or a similar rephrasing is a good idea. Conflicts from mergy operations are perfectly normal parts of a regular workday, and it is not a "problem" that needs to be "fixed". Both words scare the user by implying something is broken (or worse, "git broke something") in the contents of user's repository. There are existing messages that use the verb "fix" on "conflicts", only because it is shorter than "resolve", but this one that calls a conflict a "problem" goes too far in the wrong direction.
I agree. Still, experienced users probably have their advice.statushints disabled and won't have any problems resolving a conflict. However, for "beginners" that need the advices, resolving a conflict may not seem as trivial as it is. And even though the word "problem" may scare them, it will attract their attention. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html