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

From: Michael J Gruber <git@grubix.eu>
Date: Apr 7, 2017, 14:14 UTC
Message-ID: <1389252d-c744-b389-85c5-fb19e984048f@grubix.eu>
In-Reply-To: <xmqq8tnlz53m.fsf@gitster.mtv.corp.google.com>

Junio C Hamano venit, vidit, dixit 31.03.2017 20:14:

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

With my change, "git status --porcelain" output does not change at all (and neither does that of "git status --short"). They change only when "--inprogress" (and "--branch") is requested, just like with "--branch".

I don't know the v2 format - it seems that it's built to be extensible, but I have not checked whether that#s documented somewhere, and I didn't change it anyways.

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.

All followed the same structure. I did it that way so that it's clearer which test is failing, but I don't mind putting things together as you describe. Most of the time, one has to check where in the &&-chain a test failed, anyways.

Michael