Kong Lucien <Lucien.Kong@xxxxxxxxxxxxxxx> writes:
> The case of conflicts during a rebase -i is now taken care of. The form
> of the tests has also been modified.
> diff --git a/t/t7060-wtstatus.sh b/t/t7060-wtstatus.sh
> index b8cb490..4326df7 100755
> --- a/t/t7060-wtstatus.sh
> +++ b/t/t7060-wtstatus.sh
> @@ -30,6 +30,9 @@ test_expect_success 'Report new path with conflict' '
>
> cat >expect <<EOF
> # On branch side
> +# You have unmerged paths.
> +# (fix conflicts and run "git commit")
> +#
> # Unmerged paths:
> # (use "git add/rm <file>..." as appropriate to mark resolution)
> #
> @@ -118,4 +121,65 @@ test_expect_success 'git diff-index --cached -C shows 2 copies + 1 unmerged' '
> test_cmp expected actual
> '
These probably would want to become test_i18ncmp.
Other than that, modulo message details, the code structure is very
pleasant to follow and this patch looks ready to be tested.
Good job.
> diff --git a/wt-status.c b/wt-status.c
> index dd6d8c4..2b19fe3 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -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.
--
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