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

From: Jacob Keller <jacob.keller@gmail.com>
Date: Apr 7, 2017, 16:18 UTC
Message-ID: <CA+P7+xr37owZbCnwVKh0y_vUny9_pP380Y8sFA+7A-hv0Oc6AA@mail.gmail.com>
In-Reply-To: <xmqq8tnlz53m.fsf@gitster.mtv.corp.google.com>

On Fri, Mar 31, 2017 at 11:14 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 22 quoted lines

> 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).
>

Personally, I would want this to become the default and not have a new option to trigger it. I think we could also extend the porcelain format to include this information as well, but I'm not too familiar with how the v2 format extends or not.

Thanks, Jake

Show 35 quoted lines

>> 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.