All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Keller <jacob.keller@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Michael J Gruber <git@grubix.eu>, Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCH] status: show in-progress info for short status
Date: Fri, 7 Apr 2017 09:18:01 -0700	[thread overview]
Message-ID: <CA+P7+xr37owZbCnwVKh0y_vUny9_pP380Y8sFA+7A-hv0Oc6AA@mail.gmail.com> (raw)
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:
> 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

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

  parent reply	other threads:[~2017-04-07 16:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-31 13:59 [PATCH] status: show in-progress info for short status Michael J Gruber
2017-03-31 18:14 ` Junio C Hamano
2017-04-07 14:14   ` Michael J Gruber
2017-04-07 16:18   ` Jacob Keller [this message]
2017-04-13  6:09     ` Junio C Hamano
2017-04-13  7:20       ` Jacob Keller
2017-05-11  2:45         ` Junio C Hamano
2017-04-13  7:21       ` Jacob Keller
2017-04-01 13:51 ` brian m. carlson
2017-04-06 14:33 ` SZEDER Gábor
2017-04-07 14:05   ` Michael J Gruber
2017-04-13 10:43     ` SZEDER Gábor
2017-04-17  7:06 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CA+P7+xr37owZbCnwVKh0y_vUny9_pP380Y8sFA+7A-hv0Oc6AA@mail.gmail.com \
    --to=jacob.keller@gmail.com \
    --cc=git@grubix.eu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.