I like the idea.
Nguyễn Thái Ngọc Duy <[email protected]> writes:
> diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
> index b3f6eb9..096ba6f 100755
> --- a/t/t7512-status-help.sh
> +++ b/t/t7512-status-help.sh
> @@ -76,7 +76,7 @@ test_expect_success 'status when rebase in progress before
> resolving conflicts'
> test_must_fail git rebase HEAD^ --onto HEAD^^ &&
> cat >expected <<-\EOF &&
> # Not currently on any branch.
> - # You are currently rebasing.
> + # You are currently rebasing '\''rebase_conflicts'\''.
Perhaps "rebasing *branch* 'rebase_conflicts'"
Or even "rebasing branch 'rebase_conflicts' on <sha1sum>"
?
> @@ -923,7 +947,7 @@ static void show_bisect_in_progress(struct wt_status *s,
> struct wt_status_state *state,
> const char *color)
> {
> - status_printf_ln(s, color, _("You are currently bisecting."));
> + status_printf_ln(s, color, _("You are currently bisecting '%s'."),
> state->branch);
> if (advice_status_hints)
> status_printf_ln(s, color,
> _(" (use \"git bisect reset\" to get back to the
> original branch)"));
In the "rebase" case, you test state->branch for null-ness. Don't you
need the same test here? (What happens if you start a bisect from a
detached HEAD state?)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
