Re: [PATCH] status: show in-progress info for short status

[Junio C Hamano <gitster@pobox.com>]

Michael J Gruber <git@grubix.eu> writes:

> Ordinary (long) status shows information about bisect, revert, am,
> rebase, cherry-pick in progress, and so does git-prompt.sh. status
> --short currently shows none of this information.
>
> Introduce an `--inprogress` argument to git status so that, when used with
> `--short --branch`, in-progress information is shown next to the branch
> information. Just like `--branch`, this comes with a config option.
>
> The wording for the in-progress information is taken over from
> git-prompt.sh.
>
> Signed-off-by: Michael J Gruber <git@grubix.eu>

I haven't formed an opinion on the feature itself, or the way it is
triggered, so I won't comment on them.  I just say --porcelain (any
version) may (or may not) want to be extended in backward compatible
way (but again I haven't formed an opinion on the issue--I just know
and say there is an issue there that needs to be considered at this
point).

> diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
> index 458608cc1e..103e006249 100755
> --- a/t/t7512-status-help.sh
> +++ b/t/t7512-status-help.sh
> @@ -74,7 +74,6 @@ test_expect_success 'prepare for rebase conflicts' '
>  
>  
>  test_expect_success 'status when rebase in progress before resolving conflicts' '
> -	test_when_finished "git rebase --abort" &&
>  	ONTO=$(git rev-parse --short HEAD^^) &&
>  	test_must_fail git rebase HEAD^ --onto HEAD^^ &&
>  	cat >expected <<EOF &&
> @@ -96,6 +95,15 @@ EOF
>  	test_i18ncmp expected actual
>  '
>  
> +test_expect_success 'short status when rebase in progress' '
> +	test_when_finished "git rebase --abort" &&
> +	cat >expected <<EOF &&
> +## HEAD (no branch); REBASE-m
> +UU main.txt
> +EOF
> +	git status --untracked-files=no --short --branch --inprogress >actual &&
> +	test_i18ncmp expected actual
> +'

This is not a good way to structure the test.  If the one in the
previous hunk is what creates a conflicted state by running
"rebase", check the status output from within that test, after the
conflicting "rebase" fails and other things the existing test checks
are tested.  That way, you do not have to worry about this new check
getting confused if the previous one fails in the middle.

Likewise for the most (if not all---I didn't check very carefully)
of the remaining hunks in this test script.