On Tue, Jan 29, 2013 at 7:31 PM, Matthieu Moy
<[email protected]> wrote:
> 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'"
Looks good. One minor thing, if the ref happens to be
refs/somewhere-not-in-heads, should we still say "rebasing branch
'refs/...'" or just "rebasing 'refs/...'", or something else?
>
> Or even "rebasing branch 'rebase_conflicts' on <sha1sum>"
<sha1sum> being SHA-1 of HEAD? Why would you need it? In short
version, not full SHA-1?
> ?
>
>> @@ -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?)
I did read git-bisect.sh. I did not think it allowed bisecting on
detached HEAD. A simple test just told me otherwise. Will update.
--
Duy
--
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
