Re: [bug] Adding -z to git status seems to disable relative path

From: Jeff King <peff@peff.net>
Date: Dec 16, 2019, 06:34 UTC
Message-ID: <20191216063425.GA2127604@coredump.intra.peff.net>
In-Reply-To: <CAK60LiX0g8mNVH5YY0JNOuUNRNYp+URt=2MyH758OAWpX_Phxg@mail.gmail.com>

On Sun, Dec 15, 2019 at 09:31:23PM +0100, pp yy wrote:

Show 14 quoted lines

> Maybe i missed something but i can't get relativepath when adding '-z'
> 
> $ git --version
> git version 2.17.1
> $ git status -s test
> ?? test
> $ git status -s -z test
> ?? plugins/git/test
> $ git -c status.relativePaths=true status -s test
> ?? test
> $ git -c status.relativePaths=true status -s -z test
> ?? plugins/git/test
> 
> Bug or did i missed something ?

I think it's a bug. At first I thought you were running up against the implied porcelain output:

  -z
      Terminate entries with NUL, instead of LF. This implies the
      --porcelain=v1 output format if no other format is given.

but you are explicitly saying "-s" (and running this in a terminal shows that the result is colorized, which means we're triggering the short format and not porcelain).

And indeed, the "-z" code path seems to ignore the prefix entirely. Something like this would fix it:

diff --git a/wt-status.c b/wt-status.c
index cc6f94504d..3a0e479407 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1837,9 +1837,13 @@ static void wt_shortstatus_status(struct string_list_item *it,
 		putchar(' ');
 	putchar(' ');
 	if (s->null_termination) {
-		fprintf(stdout, "%s%c", it->string, 0);
+		struct strbuf scratch = STRBUF_INIT;
+		fprintf(stdout, "%s%c",
+			relative_path(it->string, s->prefix, &scratch), 0);
 		if (d->rename_source)
-			fprintf(stdout, "%s%c", d->rename_source, 0);
+			fprintf(stdout, "%s%c",
+				relative_path(d->rename_source, s->prefix, &scratch), 0);
+		strbuf_release(&scratch);
 	} else {
 		struct strbuf onebuf = STRBUF_INIT;
 		const char *one;

Now I do think it's a little weird to use "-z" with "--short" in the
first place, since the whole point of "-z" is make something that can be
parsed. And the whole point of "--short" versus "--porcelain" is that
the latter is stable and predictable (so it doesn't respect config at
all).

But I guess I could imagine a use case where a script is taking in paths
from the "-z" and then showing them to the user without further
processing (and so it's convenient to get the relative path directly
rather than computing them itself). I do wonder if there are any other
surprises in "--short" that might be lurking, though (IIRC, we do not
even promise that the output will stay syntactically the same between
versions; it could change to something completely different, or add new
lines in future versions).

-Peff