{"thread":{"id":"45564","subject":"[PATCH] status: show in-progress info for short status","startedAt":"2017-03-31T13:59:25Z","lastAt":"2017-05-11T02:46:07Z","messageCount":13,"participants":["Michael J Gruber","Junio C Hamano","brian m. carlson","SZEDER Gábor","Jacob Keller"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"315893","messageId":"2c3c8028cd057428758bb1e21a064a264936de90.1490968428.git.git@grubix.eu","threadId":"45564","inReplyTo":null,"subject":"[PATCH] status: show in-progress info for short status","fromName":"Michael J Gruber","fromEmail":"git@grubix.eu","sentAt":"2017-03-31T13:59:17Z","receivedAt":"2017-03-31T13:59:25Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Ordinary (long) status shows information about bisect, revert, am,\nrebase, cherry-pick in progress, and so does git-prompt.sh. status\n--short currently shows none of this information.\n\nIntroduce an `--inprogress` argument to git status so that, when used with\n`--short --branch`, in-progress information is shown next to the branch\ninformation. Just like `--branch`, this comes with a config option.\n\nThe wording for the in-progress information is taken over from\ngit-prompt.sh.\n\nSigned-off-by: Michael J Gruber <git@grubix.eu>\n---\nWhen used with --porcelain, this gives an easy way to amend the powerline-gitstatus\nprompt for example (in use locally here), and certainly others.\n\nI don't touch --porcelain=v2 - that one reads in-progress state but does not seem\nto display it. I don't know which parts are supposed to be stable for v2. \n\n Documentation/config.txt     |  4 +++\n Documentation/git-status.txt |  5 ++++\n builtin/commit.c             | 13 ++++++++++\n t/t7512-status-help.sh       | 58 ++++++++++++++++++++++++++++++++++++++++----\n wt-status.c                  | 32 +++++++++++++++++++++---\n wt-status.h                  |  1 +\n 6 files changed, 105 insertions(+), 8 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 475e874d51..3adc65f9d3 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -2957,6 +2957,10 @@ status.branch::\n \tSet to true to enable --branch by default in linkgit:git-status[1].\n \tThe option --no-branch takes precedence over this variable.\n \n+status.inprogress::\n+\tSet to true to enable --inprogress by default in linkgit:git-status[1].\n+\tThe option --no-inprogress takes precedence over this variable.\n+\n status.displayCommentPrefix::\n \tIf set to true, linkgit:git-status[1] will insert a comment\n \tprefix before each output line (starting with\ndiff --git a/Documentation/git-status.txt b/Documentation/git-status.txt\nindex ba873657cf..4fac073247 100644\n--- a/Documentation/git-status.txt\n+++ b/Documentation/git-status.txt\n@@ -32,6 +32,11 @@ OPTIONS\n --branch::\n \tShow the branch and tracking info even in short-format.\n \n+-p::\n+--inprogress::\n+\tWhen showing branch and tracking info in short-format,\n+\tshow in-progress information (BISECTING, MERGING etc.), too.\n+\n --porcelain[=<version>]::\n \tGive the output in an easy-to-parse format for scripts.\n \tThis is similar to the short output, but will remain stable\ndiff --git a/builtin/commit.c b/builtin/commit.c\nindex 4e288bc513..6176dd2c2f 100644\n--- a/builtin/commit.c\n+++ b/builtin/commit.c\n@@ -1105,8 +1105,10 @@ static const char *read_commit_message(const char *name)\n static struct status_deferred_config {\n \tenum wt_status_format status_format;\n \tint show_branch;\n+\tint show_inprogress;\n } status_deferred_config = {\n \tSTATUS_FORMAT_UNSPECIFIED,\n+\t-1, /* unspecified */\n \t-1 /* unspecified */\n };\n \n@@ -1133,6 +1135,10 @@ static void finalize_deferred_config(struct wt_status *s)\n \t\ts->show_branch = status_deferred_config.show_branch;\n \tif (s->show_branch < 0)\n \t\ts->show_branch = 0;\n+\tif (use_deferred_config && s->show_inprogress < 0)\n+\t\ts->show_inprogress = status_deferred_config.show_inprogress;\n+\tif (s->show_inprogress < 0)\n+\t\ts->show_inprogress = 0;\n }\n \n static int parse_and_validate_options(int argc, const char *argv[],\n@@ -1291,6 +1297,10 @@ static int git_status_config(const char *k, const char *v, void *cb)\n \t\tstatus_deferred_config.show_branch = git_config_bool(k, v);\n \t\treturn 0;\n \t}\n+\tif (!strcmp(k, \"status.inprogress\")) {\n+\t\tstatus_deferred_config.show_inprogress = git_config_bool(k, v);\n+\t\treturn 0;\n+\t}\n \tif (!strcmp(k, \"status.color\") || !strcmp(k, \"color.status\")) {\n \t\ts->use_color = git_config_colorbool(k, v);\n \t\treturn 0;\n@@ -1339,6 +1349,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n \t\t\t    N_(\"show status concisely\"), STATUS_FORMAT_SHORT),\n \t\tOPT_BOOL('b', \"branch\", &s.show_branch,\n \t\t\t N_(\"show branch information\")),\n+\t\tOPT_BOOL('p', \"inprogress\", &s.show_inprogress,\n+\t\t\t N_(\"show in-progress information\")),\n \t\t{ OPTION_CALLBACK, 0, \"porcelain\", &status_format,\n \t\t  N_(\"version\"), N_(\"machine-readable output\"),\n \t\t  PARSE_OPT_OPTARG, opt_parse_porcelain },\n@@ -1612,6 +1624,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n \t\tOPT_SET_INT(0, \"short\", &status_format, N_(\"show status concisely\"),\n \t\t\t    STATUS_FORMAT_SHORT),\n \t\tOPT_BOOL(0, \"branch\", &s.show_branch, N_(\"show branch information\")),\n+\t\tOPT_BOOL(0, \"inprogress\", &s.show_inprogress, N_(\"show in-progress information\")),\n \t\tOPT_SET_INT(0, \"porcelain\", &status_format,\n \t\t\t    N_(\"machine-readable output\"), STATUS_FORMAT_PORCELAIN),\n \t\tOPT_SET_INT(0, \"long\", &status_format,\ndiff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh\nindex 458608cc1e..103e006249 100755\n--- a/t/t7512-status-help.sh\n+++ b/t/t7512-status-help.sh\n@@ -74,7 +74,6 @@ test_expect_success 'prepare for rebase conflicts' '\n \n \n test_expect_success 'status when rebase in progress before resolving conflicts' '\n-\ttest_when_finished \"git rebase --abort\" &&\n \tONTO=$(git rev-parse --short HEAD^^) &&\n \ttest_must_fail git rebase HEAD^ --onto HEAD^^ &&\n \tcat >expected <<EOF &&\n@@ -96,6 +95,15 @@ EOF\n \ttest_i18ncmp expected actual\n '\n \n+test_expect_success 'short status when rebase in progress' '\n+\ttest_when_finished \"git rebase --abort\" &&\n+\tcat >expected <<EOF &&\n+## HEAD (no branch); REBASE-m\n+UU main.txt\n+EOF\n+\tgit status --untracked-files=no --short --branch --inprogress >actual &&\n+\ttest_i18ncmp expected actual\n+'\n \n test_expect_success 'status when rebase in progress before rebase --continue' '\n \tgit reset --hard rebase_conflicts &&\n@@ -133,7 +141,6 @@ test_expect_success 'prepare for rebase_i_conflicts' '\n \n \n test_expect_success 'status during rebase -i when conflicts unresolved' '\n-\ttest_when_finished \"git rebase --abort\" &&\n \tONTO=$(git rev-parse --short rebase_i_conflicts) &&\n \tLAST_COMMIT=$(git rev-parse --short rebase_i_conflicts_second) &&\n \ttest_must_fail git rebase -i rebase_i_conflicts &&\n@@ -159,6 +166,16 @@ EOF\n \ttest_i18ncmp expected actual\n '\n \n+test_expect_success 'short status during rebase -i when conflicts unresolved' '\n+\ttest_when_finished \"git rebase --abort\" &&\n+\tcat >expected <<EOF &&\n+## HEAD (no branch); REBASE-i\n+UU main.txt\n+EOF\n+\tgit status --untracked-files=no --short --branch --inprogress >actual &&\n+\ttest_i18ncmp expected actual\n+'\n+\n \n test_expect_success 'status during rebase -i after resolving conflicts' '\n \tgit reset --hard rebase_i_conflicts_second &&\n@@ -613,7 +630,6 @@ test_expect_success 'prepare am_session' '\n \n test_expect_success 'status in an am session: file already exists' '\n \tgit checkout -b am_already_exists &&\n-\ttest_when_finished \"rm Maildir/* && git am --abort\" &&\n \tgit format-patch -1 -oMaildir &&\n \ttest_must_fail git am Maildir/*.patch &&\n \tcat >expected <<\\EOF &&\n@@ -629,6 +645,14 @@ EOF\n \ttest_i18ncmp expected actual\n '\n \n+test_expect_success 'short status in an am session: file already exists' '\n+\ttest_when_finished \"rm Maildir/* && git am --abort\" &&\n+\tcat >expected <<\\EOF &&\n+## am_already_exists; AM\n+EOF\n+\tgit status --untracked-files=no --short --branch --inprogress >actual &&\n+\ttest_i18ncmp expected actual\n+'\n \n test_expect_success 'status in an am session: file does not exist' '\n \tgit reset --hard am_session &&\n@@ -681,7 +705,6 @@ test_expect_success 'status when bisecting' '\n \ttest_commit one_bisect main.txt one &&\n \ttest_commit two_bisect main.txt two &&\n \ttest_commit three_bisect main.txt three &&\n-\ttest_when_finished \"git bisect reset\" &&\n \tgit bisect start &&\n \tgit bisect bad &&\n \tgit bisect good one_bisect &&\n@@ -697,6 +720,14 @@ EOF\n \ttest_i18ncmp expected actual\n '\n \n+test_expect_success 'short status when bisecting' '\n+\ttest_when_finished \"git bisect reset\" &&\n+\tcat >expected <<EOF &&\n+## HEAD (no branch); BISECTING\n+EOF\n+\tgit status --untracked-files=no --short --branch --inprogress >actual &&\n+\ttest_i18ncmp expected actual\n+'\n \n test_expect_success 'status when rebase conflicts with statushints disabled' '\n \tgit reset --hard master &&\n@@ -736,7 +767,6 @@ test_expect_success 'prepare for cherry-pick conflicts' '\n \n \n test_expect_success 'status when cherry-picking before resolving conflicts' '\n-\ttest_when_finished \"git cherry-pick --abort\" &&\n \ttest_must_fail git cherry-pick cherry_branch_second &&\n \tTO_CHERRY_PICK=$(git rev-parse --short CHERRY_PICK_HEAD) &&\n \tcat >expected <<EOF &&\n@@ -756,6 +786,15 @@ EOF\n \ttest_i18ncmp expected actual\n '\n \n+test_expect_success 'short status when cherry-picking before resolving conflicts' '\n+\ttest_when_finished \"git cherry-pick --abort\" &&\n+\tcat >expected <<EOF &&\n+## cherry_branch; CHERRY-PICKING\n+UU main.txt\n+EOF\n+\tgit status --untracked-files=no --short --branch --inprogress >actual &&\n+\ttest_i18ncmp expected actual\n+'\n \n test_expect_success 'status when cherry-picking after resolving conflicts' '\n \tgit reset --hard cherry_branch &&\n@@ -827,6 +866,15 @@ EOF\n \ttest_i18ncmp expected actual\n '\n \n+test_expect_success 'short status while reverting commit (conflicts)' '\n+\tcat >expected <<EOF &&\n+## master; REVERTING\n+UU to-revert.txt\n+EOF\n+\tgit status --untracked-files=no --short --branch --inprogress >actual &&\n+\ttest_i18ncmp expected actual\n+'\n+\n test_expect_success 'status while reverting commit (conflicts resolved)' '\n \techo reverted >to-revert.txt &&\n \tgit add to-revert.txt &&\ndiff --git a/wt-status.c b/wt-status.c\nindex 308cf3779e..f4606d27c8 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -1715,6 +1715,7 @@ static void wt_shortstatus_other(struct string_list_item *it,\n static void wt_shortstatus_print_tracking(struct wt_status *s)\n {\n \tstruct branch *branch;\n+\tstruct wt_status_state state;\n \tconst char *header_color = color(WT_STATUS_HEADER, s);\n \tconst char *branch_color_local = color(WT_STATUS_LOCAL_BRANCH, s);\n \tconst char *branch_color_remote = color(WT_STATUS_REMOTE_BRANCH, s);\n@@ -1738,7 +1739,7 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)\n \tif (!strcmp(s->branch, \"HEAD\")) {\n \t\tcolor_fprintf(s->fp, color(WT_STATUS_NOBRANCH, s), \"%s\",\n \t\t\t      LABEL(N_(\"HEAD (no branch)\")));\n-\t\tgoto conclude;\n+\t\tgoto inprogress;\n \t}\n \n \tskip_prefix(branch_name, \"refs/heads/\", &branch_name);\n@@ -1749,7 +1750,7 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)\n \n \tif (stat_tracking_info(branch, &num_ours, &num_theirs, &base) < 0) {\n \t\tif (!base)\n-\t\t\tgoto conclude;\n+\t\t\tgoto inprogress;\n \n \t\tupstream_is_gone = 1;\n \t}\n@@ -1760,7 +1761,7 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)\n \tfree((char *)base);\n \n \tif (!upstream_is_gone && !num_ours && !num_theirs)\n-\t\tgoto conclude;\n+\t\tgoto inprogress;\n \n \tcolor_fprintf(s->fp, header_color, \" [\");\n \tif (upstream_is_gone) {\n@@ -1779,6 +1780,31 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)\n \t}\n \n \tcolor_fprintf(s->fp, header_color, \"]\");\n+\n+ inprogress:\n+\tif (!s->show_inprogress)\n+\t\tgoto conclude;\n+\tmemset(&state, 0, sizeof(state));\n+\twt_status_get_state(&state,\n+\t\t\t    s->branch && !strcmp(s->branch, \"HEAD\"));\n+\tif (state.merge_in_progress)\n+\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"MERGING\")));\n+\telse if (state.am_in_progress)\n+\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"AM\")));\n+\telse if (state.rebase_in_progress)\n+\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"REBASE-m\")));\n+\telse if (state.rebase_interactive_in_progress)\n+\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"REBASE-i\")));\n+\telse if (state.cherry_pick_in_progress)\n+\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"CHERRY-PICKING\")));\n+\telse if (state.revert_in_progress)\n+\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"REVERTING\")));\n+\tif (state.bisect_in_progress)\n+\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"BISECTING\")));\n+\tfree(state.branch);\n+\tfree(state.onto);\n+\tfree(state.detached_from);\n+\n  conclude:\n \tfputc(s->null_termination ? '\\0' : '\\n', s->fp);\n }\ndiff --git a/wt-status.h b/wt-status.h\nindex 54fec77032..8f6c9e0e62 100644\n--- a/wt-status.h\n+++ b/wt-status.h\n@@ -77,6 +77,7 @@ struct wt_status {\n \tunsigned colopts;\n \tint null_termination;\n \tint show_branch;\n+\tint show_inprogress;\n \tint hints;\n \n \tenum wt_status_format status_format;\n-- \n2.12.2.739.gfc3eb97820\n\n"},{"id":"315941","messageId":"xmqq8tnlz53m.fsf@gitster.mtv.corp.google.com","threadId":"45564","inReplyTo":"2c3c8028cd057428758bb1e21a064a264936de90.1490968428.git.git@grubix.eu","subject":"Re: [PATCH] status: show in-progress info for short status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-03-31T18:14:05Z","receivedAt":"2017-03-31T18:14:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@grubix.eu> writes:\n\n> Ordinary (long) status shows information about bisect, revert, am,\n> rebase, cherry-pick in progress, and so does git-prompt.sh. status\n> --short currently shows none of this information.\n>\n> Introduce an `--inprogress` argument to git status so that, when used with\n> `--short --branch`, in-progress information is shown next to the branch\n> information. Just like `--branch`, this comes with a config option.\n>\n> The wording for the in-progress information is taken over from\n> git-prompt.sh.\n>\n> Signed-off-by: Michael J Gruber <git@grubix.eu>\n\nI haven't formed an opinion on the feature itself, or the way it is\ntriggered, so I won't comment on them.  I just say --porcelain (any\nversion) may (or may not) want to be extended in backward compatible\nway (but again I haven't formed an opinion on the issue--I just know\nand say there is an issue there that needs to be considered at this\npoint).\n\n> diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh\n> index 458608cc1e..103e006249 100755\n> --- a/t/t7512-status-help.sh\n> +++ b/t/t7512-status-help.sh\n> @@ -74,7 +74,6 @@ test_expect_success 'prepare for rebase conflicts' '\n>  \n>  \n>  test_expect_success 'status when rebase in progress before resolving conflicts' '\n> -\ttest_when_finished \"git rebase --abort\" &&\n>  \tONTO=$(git rev-parse --short HEAD^^) &&\n>  \ttest_must_fail git rebase HEAD^ --onto HEAD^^ &&\n>  \tcat >expected <<EOF &&\n> @@ -96,6 +95,15 @@ EOF\n>  \ttest_i18ncmp expected actual\n>  '\n>  \n> +test_expect_success 'short status when rebase in progress' '\n> +\ttest_when_finished \"git rebase --abort\" &&\n> +\tcat >expected <<EOF &&\n> +## HEAD (no branch); REBASE-m\n> +UU main.txt\n> +EOF\n> +\tgit status --untracked-files=no --short --branch --inprogress >actual &&\n> +\ttest_i18ncmp expected actual\n> +'\n\nThis is not a good way to structure the test.  If the one in the\nprevious hunk is what creates a conflicted state by running\n\"rebase\", check the status output from within that test, after the\nconflicting \"rebase\" fails and other things the existing test checks\nare tested.  That way, you do not have to worry about this new check\ngetting confused if the previous one fails in the middle.\n\nLikewise for the most (if not all---I didn't check very carefully)\nof the remaining hunks in this test script.\n"},{"id":"316007","messageId":"20170401135152.sorijliupquoxk5j@genre.crustytoothpaste.net","threadId":"45564","inReplyTo":"2c3c8028cd057428758bb1e21a064a264936de90.1490968428.git.git@grubix.eu","subject":"Re: [PATCH] status: show in-progress info for short status","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2017-04-01T13:51:52Z","receivedAt":"2017-04-01T13:52:04Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Fri, Mar 31, 2017 at 03:59:17PM +0200, Michael J Gruber wrote:\n> Ordinary (long) status shows information about bisect, revert, am,\n> rebase, cherry-pick in progress, and so does git-prompt.sh. status\n> --short currently shows none of this information.\n> \n> Introduce an `--inprogress` argument to git status so that, when used with\n> `--short --branch`, in-progress information is shown next to the branch\n> information. Just like `--branch`, this comes with a config option.\n\nI don't have a strong opinion on this feature, but I would note that to\nbe consistent with other options, we'd probably want to write this as\n--in-progress (with an extra dash).\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\n+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"316281","messageId":"20170406143342.14770-1-szeder.dev@gmail.com","threadId":"45564","inReplyTo":"2c3c8028cd057428758bb1e21a064a264936de90.1490968428.git.git@grubix.eu","subject":"Re: [PATCH] status: show in-progress info for short status","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2017-04-06T14:33:42Z","receivedAt":"2017-04-06T14:34:00Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"> @@ -1779,6 +1780,31 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)\n>  \t}\n>  \n>  \tcolor_fprintf(s->fp, header_color, \"]\");\n> +\n> + inprogress:\n> +\tif (!s->show_inprogress)\n> +\t\tgoto conclude;\n> +\tmemset(&state, 0, sizeof(state));\n> +\twt_status_get_state(&state,\n> +\t\t\t    s->branch && !strcmp(s->branch, \"HEAD\"));\n> +\tif (state.merge_in_progress)\n> +\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"MERGING\")));\n> +\telse if (state.am_in_progress)\n> +\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"AM\")));\n> +\telse if (state.rebase_in_progress)\n> +\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"REBASE-m\")));\n> +\telse if (state.rebase_interactive_in_progress)\n> +\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"REBASE-i\")));\n> +\telse if (state.cherry_pick_in_progress)\n> +\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"CHERRY-PICKING\")));\n> +\telse if (state.revert_in_progress)\n> +\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"REVERTING\")));\n> +\tif (state.bisect_in_progress)\n\nelse if?\n\n> +\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"BISECTING\")));\n> +\tfree(state.branch);\n> +\tfree(state.onto);\n> +\tfree(state.detached_from);\n> +\n>   conclude:\n>  \tfputc(s->null_termination ? '\\0' : '\\n', s->fp);\n>  }\n\nThis reminded me of a patch that I have been using for almost two\nyears now...\n\ngit-prompt.sh's similar long conditional chain to show the ongoing\noperation has an else-branch at the end showing \"AM/REBASE\".  Your\npatch doesn't add an equivalent branch.  Is this intentional or an\noversight?\n\nI suppose it's intentional, because that \"AM/REBASE\" branch in the\nprompt seems to be unreachable (see below), but I never took the\neffort to actually check that (hence the \"seems\" and that's why I\nnever submitted it).\n\n\n\n -- >8 --\n\nSubject: [PATCH] bash prompt: remove unreachable ongoing \"AM/REBASE\" fallback\n\nBack in the day it was impossible to tell an ongoing 'am' and \"plain\"\n'rebase' (i.e. non-interactive, non-merge) apart, thus the prompt\ndisplayed \"AM/REBASE\" in those cases, see e75201963 (Improve bash\nprompt to detect various states like an unfinished merge, 2007-09-30).\nLater 3041c3243 (am: --rebasing, 2008-03-04) made it possible to tell\nthose cases apart and made __git_ps1() use this right away to display\neither \"AM\" or \"REBASE\", respectively.  However, it left that\n\"AM/REBASE\" in an else-branch as a fallback, but it seems to have been\nimpossible to reach even back then.\n\nThis ancient unreachable else-branch has survived to this day, remove\nit finally.\n\nSigned-off-by: SZEDER Gábor <szeder.dev@gmail.com>\n---\n contrib/completion/git-prompt.sh | 2 --\n 1 file changed, 2 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex c6cbef38c..d13af41f2 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -411,8 +411,6 @@ __git_ps1 ()\n \t\t\t\tr=\"|REBASE\"\n \t\t\telif [ -f \"$g/rebase-apply/applying\" ]; then\n \t\t\t\tr=\"|AM\"\n-\t\t\telse\n-\t\t\t\tr=\"|AM/REBASE\"\n \t\t\tfi\n \t\telif [ -f \"$g/MERGE_HEAD\" ]; then\n \t\t\tr=\"|MERGING\"\n-- \n2.12.2.613.g9c5b79913\n\n"},{"id":"316352","messageId":"33eebca1-b78f-1e9c-539c-120e32ecfded@grubix.eu","threadId":"45564","inReplyTo":"20170406143342.14770-1-szeder.dev@gmail.com","subject":"Re: [PATCH] status: show in-progress info for short status","fromName":"Michael J Gruber","fromEmail":"git@grubix.eu","sentAt":"2017-04-07T14:05:28Z","receivedAt":"2017-04-07T14:05:38Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"SZEDER Gábor venit, vidit, dixit 06.04.2017 16:33:\n>> @@ -1779,6 +1780,31 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)\n>>  \t}\n>>  \n>>  \tcolor_fprintf(s->fp, header_color, \"]\");\n>> +\n>> + inprogress:\n>> +\tif (!s->show_inprogress)\n>> +\t\tgoto conclude;\n>> +\tmemset(&state, 0, sizeof(state));\n>> +\twt_status_get_state(&state,\n>> +\t\t\t    s->branch && !strcmp(s->branch, \"HEAD\"));\n>> +\tif (state.merge_in_progress)\n>> +\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"MERGING\")));\n>> +\telse if (state.am_in_progress)\n>> +\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"AM\")));\n>> +\telse if (state.rebase_in_progress)\n>> +\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"REBASE-m\")));\n>> +\telse if (state.rebase_interactive_in_progress)\n>> +\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"REBASE-i\")));\n>> +\telse if (state.cherry_pick_in_progress)\n>> +\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"CHERRY-PICKING\")));\n>> +\telse if (state.revert_in_progress)\n>> +\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"REVERTING\")));\n>> +\tif (state.bisect_in_progress)\n> \n> else if?\n\nNo. You can do all of the above during a bisect.\n\n> \n>> +\t\tcolor_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"BISECTING\")));\n>> +\tfree(state.branch);\n>> +\tfree(state.onto);\n>> +\tfree(state.detached_from);\n>> +\n>>   conclude:\n>>  \tfputc(s->null_termination ? '\\0' : '\\n', s->fp);\n>>  }\n> \n> This reminded me of a patch that I have been using for almost two\n> years now...\n> \n> git-prompt.sh's similar long conditional chain to show the ongoing\n> operation has an else-branch at the end showing \"AM/REBASE\".  Your\n> patch doesn't add an equivalent branch.  Is this intentional or an\n> oversight?\n\nI go over all states that wt_status_get_state can give.\n\n> I suppose it's intentional, because that \"AM/REBASE\" branch in the\n> prompt seems to be unreachable (see below), but I never took the\n> effort to actually check that (hence the \"seems\" and that's why I\n> never submitted it).\n\nNote that wt_status_get_state and the prompt script do things quite\ndifferently.\n\nI suppose that the prompt could make use of the in-progress info being\nexposed by \"git status\" rather doing its on thing.\n\nMichael\n"},{"id":"316353","messageId":"1389252d-c744-b389-85c5-fb19e984048f@grubix.eu","threadId":"45564","inReplyTo":"xmqq8tnlz53m.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] status: show in-progress info for short status","fromName":"Michael J Gruber","fromEmail":"git@grubix.eu","sentAt":"2017-04-07T14:14:26Z","receivedAt":"2017-04-07T14:14:38Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 31.03.2017 20:14:\n> Michael J Gruber <git@grubix.eu> writes:\n> \n>> Ordinary (long) status shows information about bisect, revert, am,\n>> rebase, cherry-pick in progress, and so does git-prompt.sh. status\n>> --short currently shows none of this information.\n>>\n>> Introduce an `--inprogress` argument to git status so that, when used with\n>> `--short --branch`, in-progress information is shown next to the branch\n>> information. Just like `--branch`, this comes with a config option.\n>>\n>> The wording for the in-progress information is taken over from\n>> git-prompt.sh.\n>>\n>> Signed-off-by: Michael J Gruber <git@grubix.eu>\n> \n> I haven't formed an opinion on the feature itself, or the way it is\n> triggered, so I won't comment on them.  I just say --porcelain (any\n> version) may (or may not) want to be extended in backward compatible\n> way (but again I haven't formed an opinion on the issue--I just know\n> and say there is an issue there that needs to be considered at this\n> point).\n\nWith my change, \"git status --porcelain\" output does not change at all\n(and neither does that of \"git status --short\"). They change only when\n\"--inprogress\" (and \"--branch\") is requested, just like with \"--branch\".\n\nI don't know the v2 format - it seems that it's built to be extensible,\nbut I have not checked whether that#s documented somewhere, and I didn't\nchange it anyways.\n\n>> diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh\n>> index 458608cc1e..103e006249 100755\n>> --- a/t/t7512-status-help.sh\n>> +++ b/t/t7512-status-help.sh\n>> @@ -74,7 +74,6 @@ test_expect_success 'prepare for rebase conflicts' '\n>>  \n>>  \n>>  test_expect_success 'status when rebase in progress before resolving conflicts' '\n>> -\ttest_when_finished \"git rebase --abort\" &&\n>>  \tONTO=$(git rev-parse --short HEAD^^) &&\n>>  \ttest_must_fail git rebase HEAD^ --onto HEAD^^ &&\n>>  \tcat >expected <<EOF &&\n>> @@ -96,6 +95,15 @@ EOF\n>>  \ttest_i18ncmp expected actual\n>>  '\n>>  \n>> +test_expect_success 'short status when rebase in progress' '\n>> +\ttest_when_finished \"git rebase --abort\" &&\n>> +\tcat >expected <<EOF &&\n>> +## HEAD (no branch); REBASE-m\n>> +UU main.txt\n>> +EOF\n>> +\tgit status --untracked-files=no --short --branch --inprogress >actual &&\n>> +\ttest_i18ncmp expected actual\n>> +'\n> \n> This is not a good way to structure the test.  If the one in the\n> previous hunk is what creates a conflicted state by running\n> \"rebase\", check the status output from within that test, after the\n> conflicting \"rebase\" fails and other things the existing test checks\n> are tested.  That way, you do not have to worry about this new check\n> getting confused if the previous one fails in the middle.\n> \n> Likewise for the most (if not all---I didn't check very carefully)\n> of the remaining hunks in this test script.\n\nAll followed the same structure. I did it that way so that it's clearer\nwhich test is failing, but I don't mind putting things together as you\ndescribe. Most of the time, one has to check where in the &&-chain a\ntest failed, anyways.\n\nMichael\n"},{"id":"316363","messageId":"CA+P7+xr37owZbCnwVKh0y_vUny9_pP380Y8sFA+7A-hv0Oc6AA@mail.gmail.com","threadId":"45564","inReplyTo":"xmqq8tnlz53m.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] status: show in-progress info for short status","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-04-07T16:18:01Z","receivedAt":"2017-04-07T16:18:28Z","isPatch":true,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Fri, Mar 31, 2017 at 11:14 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Michael J Gruber <git@grubix.eu> writes:\n>\n>> Ordinary (long) status shows information about bisect, revert, am,\n>> rebase, cherry-pick in progress, and so does git-prompt.sh. status\n>> --short currently shows none of this information.\n>>\n>> Introduce an `--inprogress` argument to git status so that, when used with\n>> `--short --branch`, in-progress information is shown next to the branch\n>> information. Just like `--branch`, this comes with a config option.\n>>\n>> The wording for the in-progress information is taken over from\n>> git-prompt.sh.\n>>\n>> Signed-off-by: Michael J Gruber <git@grubix.eu>\n>\n> I haven't formed an opinion on the feature itself, or the way it is\n> triggered, so I won't comment on them.  I just say --porcelain (any\n> version) may (or may not) want to be extended in backward compatible\n> way (but again I haven't formed an opinion on the issue--I just know\n> and say there is an issue there that needs to be considered at this\n> point).\n>\n\nPersonally, I would want this to become the default and not have a new\noption to trigger it. I think we could also extend the porcelain\nformat to include this information as well, but I'm not too familiar\nwith how the v2 format extends or not.\n\nThanks,\nJake\n\n>> diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh\n>> index 458608cc1e..103e006249 100755\n>> --- a/t/t7512-status-help.sh\n>> +++ b/t/t7512-status-help.sh\n>> @@ -74,7 +74,6 @@ test_expect_success 'prepare for rebase conflicts' '\n>>\n>>\n>>  test_expect_success 'status when rebase in progress before resolving conflicts' '\n>> -     test_when_finished \"git rebase --abort\" &&\n>>       ONTO=$(git rev-parse --short HEAD^^) &&\n>>       test_must_fail git rebase HEAD^ --onto HEAD^^ &&\n>>       cat >expected <<EOF &&\n>> @@ -96,6 +95,15 @@ EOF\n>>       test_i18ncmp expected actual\n>>  '\n>>\n>> +test_expect_success 'short status when rebase in progress' '\n>> +     test_when_finished \"git rebase --abort\" &&\n>> +     cat >expected <<EOF &&\n>> +## HEAD (no branch); REBASE-m\n>> +UU main.txt\n>> +EOF\n>> +     git status --untracked-files=no --short --branch --inprogress >actual &&\n>> +     test_i18ncmp expected actual\n>> +'\n>\n> This is not a good way to structure the test.  If the one in the\n> previous hunk is what creates a conflicted state by running\n> \"rebase\", check the status output from within that test, after the\n> conflicting \"rebase\" fails and other things the existing test checks\n> are tested.  That way, you do not have to worry about this new check\n> getting confused if the previous one fails in the middle.\n>\n> Likewise for the most (if not all---I didn't check very carefully)\n> of the remaining hunks in this test script.\n"},{"id":"316712","messageId":"xmqqmvbkq1nn.fsf@gitster.mtv.corp.google.com","threadId":"45564","inReplyTo":"CA+P7+xr37owZbCnwVKh0y_vUny9_pP380Y8sFA+7A-hv0Oc6AA@mail.gmail.com","subject":"Re: [PATCH] status: show in-progress info for short status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-13T06:09:32Z","receivedAt":"2017-04-13T06:09:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacob Keller <jacob.keller@gmail.com> writes:\n\n> Personally, I would want this to become the default and not have a new\n> option to trigger it. I think we could also extend the porcelain\n> format to include this information as well, but I'm not too familiar\n> with how the v2 format extends or not.\n\nI think the general rule of thumb for --porcelain is that we can\nfreely introduce new record types without version bump, and expect\nthe reading scripts to ignore unrecognised records (we may need to\ndescribe this a bit more strongly in our document, though), while\nchanges to the format of existing records must require a command\nline option that cannot be turned on by default with configuration\n(or a version bump, if you want to change the output format by\ndefault).\n\nI am getting the impression that this \"we are doing X\" is a new and\ndiscinct record type that existing readers can safely ignore?  If\nthat is the case, it may be better to add it without making it\noptional.\n"},{"id":"316716","messageId":"CA+P7+xqu1oB2J2C9OoqaYAwdNOXT7f0kvHEHHZ4nXaefewBrNQ@mail.gmail.com","threadId":"45564","inReplyTo":"xmqqmvbkq1nn.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] status: show in-progress info for short status","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-04-13T07:20:19Z","receivedAt":"2017-04-13T07:20:46Z","isPatch":true,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Apr 12, 2017 at 11:09 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jacob Keller <jacob.keller@gmail.com> writes:\n>\n>> Personally, I would want this to become the default and not have a new\n>> option to trigger it. I think we could also extend the porcelain\n>> format to include this information as well, but I'm not too familiar\n>> with how the v2 format extends or not.\n>\n> I think the general rule of thumb for --porcelain is that we can\n> freely introduce new record types without version bump, and expect\n> the reading scripts to ignore unrecognised records (we may need to\n> describe this a bit more strongly in our document, though), while\n> changes to the format of existing records must require a command\n> line option that cannot be turned on by default with configuration\n> (or a version bump, if you want to change the output format by\n> default).\n>\n> I am getting the impression that this \"we are doing X\" is a new and\n> discinct record type that existing readers can safely ignore?  If\n> that is the case, it may be better to add it without making it\n> optional.\n\nCorrect. But either way we should be free to change and extend the\nnon-porcelain format without worry I thought?\n\nThanks,\nJake\n"},{"id":"316717","messageId":"CA+P7+xrCbMrun4TZtAniBY5ehObrcYHtL3XYycMaJiT0EJ9fmA@mail.gmail.com","threadId":"45564","inReplyTo":"xmqqmvbkq1nn.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] status: show in-progress info for short status","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2017-04-13T07:21:07Z","receivedAt":"2017-04-13T07:21:33Z","isPatch":true,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Wed, Apr 12, 2017 at 11:09 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jacob Keller <jacob.keller@gmail.com> writes:\n>\n>> Personally, I would want this to become the default and not have a new\n>> option to trigger it. I think we could also extend the porcelain\n>> format to include this information as well, but I'm not too familiar\n>> with how the v2 format extends or not.\n>\n> I think the general rule of thumb for --porcelain is that we can\n> freely introduce new record types without version bump, and expect\n> the reading scripts to ignore unrecognised records (we may need to\n> describe this a bit more strongly in our document, though), while\n> changes to the format of existing records must require a command\n> line option that cannot be turned on by default with configuration\n> (or a version bump, if you want to change the output format by\n> default).\n>\n> I am getting the impression that this \"we are doing X\" is a new and\n> discinct record type that existing readers can safely ignore?  If\n> that is the case, it may be better to add it without making it\n> optional.\n\nI think we are safe in extending porcelain v2.\n\nThanks,\nJake\n"},{"id":"316719","messageId":"CAM0VKjkbs1SD3YK6Um7t_Z72z8S4-xz5XpV3ywEmphMJRrmTzQ@mail.gmail.com","threadId":"45564","inReplyTo":"33eebca1-b78f-1e9c-539c-120e32ecfded@grubix.eu","subject":"Re: [PATCH] status: show in-progress info for short status","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2017-04-13T10:43:32Z","receivedAt":"2017-04-13T10:43:39Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Fri, Apr 7, 2017 at 4:05 PM, Michael J Gruber <git@grubix.eu> wrote:\n> SZEDER Gábor venit, vidit, dixit 06.04.2017 16:33:\n>>> @@ -1779,6 +1780,31 @@ static void wt_shortstatus_print_tracking(struct wt_status *s)\n>>>      }\n>>>\n>>>      color_fprintf(s->fp, header_color, \"]\");\n>>> +\n>>> + inprogress:\n>>> +    if (!s->show_inprogress)\n>>> +            goto conclude;\n>>> +    memset(&state, 0, sizeof(state));\n>>> +    wt_status_get_state(&state,\n>>> +                        s->branch && !strcmp(s->branch, \"HEAD\"));\n>>> +    if (state.merge_in_progress)\n>>> +            color_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"MERGING\")));\n>>> +    else if (state.am_in_progress)\n>>> +            color_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"AM\")));\n>>> +    else if (state.rebase_in_progress)\n>>> +            color_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"REBASE-m\")));\n\nIn the prompt \"REBASE-m\" is only shown during 'rebase --merge', while\n\"REBASE\" is shown during a plain 'rebase'.  Here \"REBASE-m\" will be\nshown during both.\n\n>>> +    else if (state.rebase_interactive_in_progress)\n>>> +            color_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"REBASE-i\")));\n>>> +    else if (state.cherry_pick_in_progress)\n>>> +            color_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"CHERRY-PICKING\")));\n>>> +    else if (state.revert_in_progress)\n>>> +            color_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"REVERTING\")));\n>>> +    if (state.bisect_in_progress)\n>>\n>> else if?\n>\n> No. You can do all of the above during a bisect.\n\nRight indeed.  I think the prompt should do the same.  Onto the TODO\nlist it goes, then.\n\n>>> +            color_fprintf(s->fp, header_color, \"; %s\", LABEL(N_(\"BISECTING\")));\n>>> +    free(state.branch);\n>>> +    free(state.onto);\n>>> +    free(state.detached_from);\n>>> +\n>>>   conclude:\n>>>      fputc(s->null_termination ? '\\0' : '\\n', s->fp);\n>>>  }\n>>\n>> This reminded me of a patch that I have been using for almost two\n>> years now...\n>>\n>> git-prompt.sh's similar long conditional chain to show the ongoing\n>> operation has an else-branch at the end showing \"AM/REBASE\".  Your\n>> patch doesn't add an equivalent branch.  Is this intentional or an\n>> oversight?\n>\n> I go over all states that wt_status_get_state can give.\n\nYeah, but are those states exclusive?  Or is it possible that both\n'am_in_progress' and 'rebase_in_progress' are set?  I suppose it's not\npossible.\nIt would certainly be more obvious if it were a single enum field\ninstead of a bunch of ints.\n\n>> I suppose it's intentional, because that \"AM/REBASE\" branch in the\n>> prompt seems to be unreachable (see below), but I never took the\n>> effort to actually check that (hence the \"seems\" and that's why I\n>> never submitted it).\n>\n> Note that wt_status_get_state and the prompt script do things quite\n> differently.\n>\n> I suppose that the prompt could make use of the in-progress info being\n> exposed by \"git status\" rather doing its on thing.\n\nThe prompt currently gets all this in-progress info using only Bash\nbuiltins, which is much faster than running a git process in a\nsubshell.  This is especially important on Windows, where the overhead\nof running a git process is large enough to make the runtime of\n__git_ps1() noticeable when displaying the prompt.  That's the main\nreason for much of the shell complexity and ugliness in git-prompt.sh.\n\nBesides, current output formats make 'git status' unsuitable for the\nprompt.\n"},{"id":"316991","messageId":"xmqqwpajikd2.fsf@gitster.mtv.corp.google.com","threadId":"45564","inReplyTo":"2c3c8028cd057428758bb1e21a064a264936de90.1490968428.git.git@grubix.eu","subject":"Re: [PATCH] status: show in-progress info for short status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-04-17T07:06:17Z","receivedAt":"2017-04-17T07:06:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@grubix.eu> writes:\n\n> Ordinary (long) status shows information about bisect, revert, am,\n> rebase, cherry-pick in progress, and so does git-prompt.sh. status\n> --short currently shows none of this information.\n>\n> Introduce an `--inprogress` argument to git status so that, when used with\n> `--short --branch`, in-progress information is shown next to the branch\n> information. Just like `--branch`, this comes with a config option.\n>\n> The wording for the in-progress information is taken over from\n> git-prompt.sh.\n>\n> Signed-off-by: Michael J Gruber <git@grubix.eu>\n> ---\n> When used with --porcelain, this gives an easy way to amend the powerline-gitstatus\n> prompt for example (in use locally here), and certainly others.\n>\n> I don't touch --porcelain=v2 - that one reads in-progress state but does not seem\n> to display it. I don't know which parts are supposed to be stable for v2. \n>\n>  Documentation/config.txt     |  4 +++\n>  Documentation/git-status.txt |  5 ++++\n>  builtin/commit.c             | 13 ++++++++++\n>  t/t7512-status-help.sh       | 58 ++++++++++++++++++++++++++++++++++++++++----\n>  wt-status.c                  | 32 +++++++++++++++++++++---\n>  wt-status.h                  |  1 +\n>  6 files changed, 105 insertions(+), 8 deletions(-)\n>\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> index 475e874d51..3adc65f9d3 100644\n> --- a/Documentation/config.txt\n> +++ b/Documentation/config.txt\n> @@ -2957,6 +2957,10 @@ status.branch::\n>  \tSet to true to enable --branch by default in linkgit:git-status[1].\n>  \tThe option --no-branch takes precedence over this variable.\n>  \n> +status.inprogress::\n> +\tSet to true to enable --inprogress by default in linkgit:git-status[1].\n> +\tThe option --no-inprogress takes precedence over this variable.\n> +\n\nHas the name of the option been discussed already and the list\nreached a consensus?  \"in progress\" is a two-word phrase, and I am\nwondering if this should be status.inProgress (and the option name\nshould be \"--in-progress\").\n\n> +-p::\n> +--inprogress::\n> +\tWhen showing branch and tracking info in short-format,\n> +\tshow in-progress information (BISECTING, MERGING etc.), too.\n> +\n\nI do not think we want to give short-and-sweet \"-p\" to this option.\n\"git log -p\" gives a patch output, \"git status -p\" sounds like it\ndoes so, too (i.e. \"git show\" plus various status).  Besides, for\nthose who are lazy, you already have a configuration variable.\n\n"},{"id":"319312","messageId":"xmqqmvakcdqw.fsf@gitster.mtv.corp.google.com","threadId":"45564","inReplyTo":"CA+P7+xqu1oB2J2C9OoqaYAwdNOXT7f0kvHEHHZ4nXaefewBrNQ@mail.gmail.com","subject":"Re: [PATCH] status: show in-progress info for short status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-11T02:45:59Z","receivedAt":"2017-05-11T02:46:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jacob Keller <jacob.keller@gmail.com> writes:\n\n> On Wed, Apr 12, 2017 at 11:09 PM, Junio C Hamano <gitster@pobox.com> wrote:\n>> Jacob Keller <jacob.keller@gmail.com> writes:\n>>\n>>> Personally, I would want this to become the default and not have a new\n>>> option to trigger it. I think we could also extend the porcelain\n>>> format to include this information as well, but I'm not too familiar\n>>> with how the v2 format extends or not.\n\nI started to do a simple s/inprogress/in-progress/ while waiting,\nbut Ævar reminded me of this discussion---and I agree with you that\nthis probably should be on.  Moreover, I think this should not be\noptional (which makes s/inprogress/in-progress/ a moot point).  \n\nMichael went the cautious route to make it optional just like the\n\"-b/--branch\" option, but I think \"-b/--branch\" was a design mistake\nand not something we want to mimic.  The long output format gives\nthe same information without \"--branch\", and giving \"--no-branch\"\ndoes not even disable the information in the long format; \"--branch\"\nis only effective in the short format, even though giving it to long\nformat does not diagnose any error.  \n\nWe should have just enhanced the feature unconditionally, I would\nthink.  But fixing that past mistake is a separate issue.\n\n>> I think the general rule of thumb for --porcelain is that we can\n>> freely introduce new record types without version bump, and expect\n>> the reading scripts to ignore unrecognised records (we may need to\n>> describe this a bit more strongly in our document, though), while\n>> changes to the format of existing records must require a command\n>> line option that cannot be turned on by default with configuration\n>> (or a version bump, if you want to change the output format by\n>> default).\n>>\n>> I am getting the impression that this \"we are doing X\" is a new and\n>> discinct record type that existing readers can safely ignore?  If\n>> that is the case, it may be better to add it without making it\n>> optional.\n>\n> Correct. But either way we should be free to change and extend the\n> non-porcelain format without worry I thought?\n\nWhile I think we should update \"short\" and \"porcelain\" at the same\ntime when it is clear that we can (e.g. we are adding a new record\ntype and we make sure that the current readers of \"porcelain\" output\nwould ignore the new record type), an update to \"porcelain\" can come\nlater, as long as we don't forget.  Otherwise people will script\naround \"short\", ignoring \"porcelain\", no?\n\nThanks.\n"}]}