* Git Status Short Output Color Inconsistency with -z Flag @ 2025-10-05 0:48 Langbart 2025-10-07 8:29 ` Jeff King 0 siblings, 1 reply; 7+ messages in thread From: Langbart @ 2025-10-05 0:48 UTC (permalink / raw) To: git@vger•kernel.org What did you do before the bug happened? (Steps to reproduce your issue) 1. Create an untracked file and modify an existing tracked file 2. Run: git status --short -z What did you expect to happen? (Expected behavior) All status markers have colors disabled What happened instead? (Actual behavior) - Modified marker (`M`) appears colored - Untracked marker (`??`) appears *uncolored* Related patch: https://lore.kernel.org/git/cover.1260025135.git.git@drmicha.warpmail.net/T/#u git version 2.51.0 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Git Status Short Output Color Inconsistency with -z Flag 2025-10-05 0:48 Git Status Short Output Color Inconsistency with -z Flag Langbart @ 2025-10-07 8:29 ` Jeff King 2025-10-07 20:34 ` [PATCH] status: make coloring of "-z --short" consistent Jeff King 0 siblings, 1 reply; 7+ messages in thread From: Jeff King @ 2025-10-07 8:29 UTC (permalink / raw) To: Langbart; +Cc: git@vger•kernel.org On Sun, Oct 05, 2025 at 12:48:43AM +0000, Langbart wrote: > What did you do before the bug happened? (Steps to reproduce your issue) > > 1. Create an untracked file and modify an existing tracked file > 2. Run: git status --short -z > > What did you expect to happen? (Expected behavior) > > All status markers have colors disabled > > What happened instead? (Actual behavior) > > - Modified marker (`M`) appears colored > - Untracked marker (`??`) appears *uncolored* There is a bug here, but I don't think your expectation matches the documentation. In the --short output, we do still respect color. We do not for the machine-readable --porcelain output, which is also implied by "-z" without another format. So either of: git status -z --porcelain # this implies --porcelain=v1 git status -z will do what you expected. Asking for "-z --short" is a bit unusual, since "--short" is meant to be human-readable and "-z" generally is not. So I'd expect it to be used only for relaying colorized information to a human over another channel or something. But back to the bug. As you noticed, one item is colorized and the other is not. I think the fix is probably this: diff --git a/wt-status.c b/wt-status.c index 8ffe6d3988..e12adb26b9 100644 --- a/wt-status.c +++ b/wt-status.c @@ -2042,13 +2042,13 @@ static void wt_shortstatus_status(struct string_list_item *it, static void wt_shortstatus_other(struct string_list_item *it, struct wt_status *s, const char *sign) { + color_fprintf(s->fp, color(WT_STATUS_UNTRACKED, s), "%s", sign); if (s->null_termination) { - fprintf(s->fp, "%s %s%c", sign, it->string, 0); + fprintf(s->fp, " %s%c", it->string, 0); } else { struct strbuf onebuf = STRBUF_INIT; const char *one; one = quote_path(it->string, s->prefix, &onebuf, QUOTE_PATH_QUOTE_SP); - color_fprintf(s->fp, color(WT_STATUS_UNTRACKED, s), "%s", sign); fprintf(s->fp, " %s\n", one); strbuf_release(&onebuf); } which matches how other output functions like wt_shortstatus_unmerged() behave (handling color before hitting the null_termination conditional). -Peff ^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH] status: make coloring of "-z --short" consistent 2025-10-07 8:29 ` Jeff King @ 2025-10-07 20:34 ` Jeff King 2025-10-17 8:44 ` [PATCH resend] " Jeff King 0 siblings, 1 reply; 7+ messages in thread From: Jeff King @ 2025-10-07 20:34 UTC (permalink / raw) To: Langbart; +Cc: git@vger•kernel.org When running "git status -z --short", the marker on modified index entries (e.g., "M") is colorized, but the "??" marker for untracked entries is not. Let's fix the "??" entries to show color here. At first glance you might think that neither should be colorized, as usually one would use "-z" to get machine-readable output. But this is a tricky and unusual case. We have two output formats, "--short" and "--porcelain", which are substantially similar but differ in that "--short" is for humans and "--porcelain" is for machines. And "-z" by itself, without any other output option, does default to "--porcelain", so "git status -z" is for machines and will not colorize anything. But if you ask for "-z" and "--short" together, then that is explicitly asking for the human-readable output, but separated by NULs. This is unlikely to be useful directly, but could for example be used if the output will be shown to a human outside of the terminal. At any rate, the current behavior is clearly wrong (since we colorize some things but not others), and I think colorizing everything is the least-surprising thing we can do here. Reported-by: Langbart <Langbart@protonmail•com> Signed-off-by: Jeff King <peff@peff•net> --- Same fix that I posted earlier, but now with a test and a commit message. t/t7508-status.sh | 11 +++++++++++ wt-status.c | 4 ++-- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/t/t7508-status.sh b/t/t7508-status.sh index cdc1d6fcc7..abad229e9d 100755 --- a/t/t7508-status.sh +++ b/t/t7508-status.sh @@ -717,6 +717,17 @@ test_expect_success TTY 'status -s with color.status' ' ' +test_expect_success TTY 'status -s keeps colors with -z' ' + test_when_finished "rm -f output.*" && + test_terminal git status -s -z >output.raw && + # convert back to newlines to avoid portability issues with + # test_decode_color and test_cmp, and to let us use the same expected + # output as earlier tests + tr "\0" "\n" <output.raw >output.nl && + test_decode_color <output.nl >output && + test_cmp expect output +' + cat >expect <<\EOF ## <YELLOW>main<RESET>...<CYAN>upstream<RESET> [ahead <YELLOW>1<RESET>, behind <CYAN>2<RESET>] <RED>M<RESET> dir1/modified diff --git a/wt-status.c b/wt-status.c index 8ffe6d3988..e12adb26b9 100644 --- a/wt-status.c +++ b/wt-status.c @@ -2042,13 +2042,13 @@ static void wt_shortstatus_status(struct string_list_item *it, static void wt_shortstatus_other(struct string_list_item *it, struct wt_status *s, const char *sign) { + color_fprintf(s->fp, color(WT_STATUS_UNTRACKED, s), "%s", sign); if (s->null_termination) { - fprintf(s->fp, "%s %s%c", sign, it->string, 0); + fprintf(s->fp, " %s%c", it->string, 0); } else { struct strbuf onebuf = STRBUF_INIT; const char *one; one = quote_path(it->string, s->prefix, &onebuf, QUOTE_PATH_QUOTE_SP); - color_fprintf(s->fp, color(WT_STATUS_UNTRACKED, s), "%s", sign); fprintf(s->fp, " %s\n", one); strbuf_release(&onebuf); } -- 2.51.0.717.g1fc658c4b9 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH resend] status: make coloring of "-z --short" consistent 2025-10-07 20:34 ` [PATCH] status: make coloring of "-z --short" consistent Jeff King @ 2025-10-17 8:44 ` Jeff King 2025-10-18 6:01 ` Langbart 0 siblings, 1 reply; 7+ messages in thread From: Jeff King @ 2025-10-17 8:44 UTC (permalink / raw) To: git; +Cc: Langbart When running "git status -z --short", the marker on modified index entries (e.g., "M") is colorized, but the "??" marker for untracked entries is not. Let's fix the "??" entries to show color here. At first glance you might think that neither should be colorized, as usually one would use "-z" to get machine-readable output. But this is a tricky and unusual case. We have two output formats, "--short" and "--porcelain" which are substantially similar, but differ in that "--short" is for humans who want something short and "--porcelain" is for machines. And "-z" by itself, without any other output option, does default to "--porcelain", so "git status -z" will not colorize anything. But if you explicitly ask for "-z" and "--short" together, then that is asking for the human-readable output, but separated by NULs. This is unlikely to be useful directly, but could for example be used if the output will be shown to a human outside of the terminal. At any rate, the current behavior is clearly wrong (since we colorize some things but not others), and I think colorizing everything is the least-surprising thing we can do here. Reported-by: Langbart <Langbart@protonmail•com> Signed-off-by: Jeff King <peff@peff•net> --- Re-sending unmodified, as the original from 10 days ago did not generate any discussion, and doesn't seem to have been picked up for 'seen'. t/t7508-status.sh | 11 +++++++++++ wt-status.c | 4 ++-- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/t/t7508-status.sh b/t/t7508-status.sh index cdc1d6fcc7..abad229e9d 100755 --- a/t/t7508-status.sh +++ b/t/t7508-status.sh @@ -717,6 +717,17 @@ test_expect_success TTY 'status -s with color.status' ' ' +test_expect_success TTY 'status -s keeps colors with -z' ' + test_when_finished "rm -f output.*" && + test_terminal git status -s -z >output.raw && + # convert back to newlines to avoid portability issues with + # test_decode_color and test_cmp, and to let us use the same expected + # output as earlier tests + tr "\0" "\n" <output.raw >output.nl && + test_decode_color <output.nl >output && + test_cmp expect output +' + cat >expect <<\EOF ## <YELLOW>main<RESET>...<CYAN>upstream<RESET> [ahead <YELLOW>1<RESET>, behind <CYAN>2<RESET>] <RED>M<RESET> dir1/modified diff --git a/wt-status.c b/wt-status.c index 8ffe6d3988..e12adb26b9 100644 --- a/wt-status.c +++ b/wt-status.c @@ -2042,13 +2042,13 @@ static void wt_shortstatus_status(struct string_list_item *it, static void wt_shortstatus_other(struct string_list_item *it, struct wt_status *s, const char *sign) { + color_fprintf(s->fp, color(WT_STATUS_UNTRACKED, s), "%s", sign); if (s->null_termination) { - fprintf(s->fp, "%s %s%c", sign, it->string, 0); + fprintf(s->fp, " %s%c", it->string, 0); } else { struct strbuf onebuf = STRBUF_INIT; const char *one; one = quote_path(it->string, s->prefix, &onebuf, QUOTE_PATH_QUOTE_SP); - color_fprintf(s->fp, color(WT_STATUS_UNTRACKED, s), "%s", sign); fprintf(s->fp, " %s\n", one); strbuf_release(&onebuf); } -- 2.51.1.685.g6bf3278fbc ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH resend] status: make coloring of "-z --short" consistent 2025-10-17 8:44 ` [PATCH resend] " Jeff King @ 2025-10-18 6:01 ` Langbart 2025-10-18 9:50 ` Jeff King 0 siblings, 1 reply; 7+ messages in thread From: Langbart @ 2025-10-18 6:01 UTC (permalink / raw) To: Jeff King; +Cc: git@vger•kernel.org Thanks for the patch. Agreed, Retaining the colors is very useful, allowing me to pipe the colored output to other tools. git -c color.status=always status --short -z | fzf --read0 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH resend] status: make coloring of "-z --short" consistent 2025-10-18 6:01 ` Langbart @ 2025-10-18 9:50 ` Jeff King 2025-10-18 15:08 ` Langbart 0 siblings, 1 reply; 7+ messages in thread From: Jeff King @ 2025-10-18 9:50 UTC (permalink / raw) To: Langbart; +Cc: git@vger•kernel.org On Sat, Oct 18, 2025 at 06:01:07AM +0000, Langbart wrote: > Thanks for the patch. Agreed, Retaining the colors is very useful, > allowing me to pipe the colored output to other tools. > > git -c color.status=always status --short -z | fzf --read0 Thanks, my intuition is that something like that could be useful, but I didn't have a concrete example. That one is perfect. (If anybody tries the above, note that I needed to add "--ansi" for it to look nice in fzf. But I don't usually use that program, so I imagine there's a way to configure it to do that by default). -Peff ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH resend] status: make coloring of "-z --short" consistent 2025-10-18 9:50 ` Jeff King @ 2025-10-18 15:08 ` Langbart 0 siblings, 0 replies; 7+ messages in thread From: Langbart @ 2025-10-18 15:08 UTC (permalink / raw) To: Jeff King; +Cc: git@vger•kernel.org > Thanks, my intuition is that something like that could be useful, but I > didn't have a concrete example. That one is perfect. Great, I'll pass it to the fzf maintainer, who proposed it. > (If anybody tries the above, note that I needed to add "--ansi" for it > to look nice in fzf. But I don't usually use that program, so I imagine > there's a way to configure it to do that by default). You're right. I only set it in my environment variable: export FZF_DEFAULT_OPTS="--ansi" Thanks for the fix and for being active here. I've come across your name a few times while searching the git.vger.kernel.org archive mirror for issues, and I've always appreciated your thoughtful replies. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2025-10-18 15:09 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-10-05 0:48 Git Status Short Output Color Inconsistency with -z Flag Langbart 2025-10-07 8:29 ` Jeff King 2025-10-07 20:34 ` [PATCH] status: make coloring of "-z --short" consistent Jeff King 2025-10-17 8:44 ` [PATCH resend] " Jeff King 2025-10-18 6:01 ` Langbart 2025-10-18 9:50 ` Jeff King 2025-10-18 15:08 ` Langbart
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox