{"thread":{"id":"52463","subject":"[bug] Adding -z to git status seems to disable relative path","startedAt":"2019-12-15T20:31:36Z","lastAt":"2019-12-18T14:04:21Z","messageCount":3,"participants":["pp yy","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"388238","messageId":"CAK60LiX0g8mNVH5YY0JNOuUNRNYp+URt=2MyH758OAWpX_Phxg@mail.gmail.com","threadId":"52463","inReplyTo":null,"subject":"[bug] Adding -z to git status seems to disable relative path","fromName":"pp yy","fromEmail":"yoann.mac.donald@gmail.com","sentAt":"2019-12-15T20:31:23Z","receivedAt":"2019-12-15T20:31:36Z","isPatch":false,"sender":{"key":"yoann.mac.donald@gmail.com","avatar":null},"body":"Hi,\n\nMaybe i missed something but i can't get relativepath when adding '-z'\n\n$ git --version\ngit version 2.17.1\n$ git status -s test\n?? test\n$ git status -s -z test\n?? plugins/git/test\n$ git -c status.relativePaths=true status -s test\n?? test\n$ git -c status.relativePaths=true status -s -z test\n?? plugins/git/test\n\nBug or did i missed something ?\n\nRegards,\n"},{"id":"388242","messageId":"20191216063425.GA2127604@coredump.intra.peff.net","threadId":"52463","inReplyTo":"CAK60LiX0g8mNVH5YY0JNOuUNRNYp+URt=2MyH758OAWpX_Phxg@mail.gmail.com","subject":"Re: [bug] Adding -z to git status seems to disable relative path","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-12-16T06:34:25Z","receivedAt":"2019-12-16T06:34:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Dec 15, 2019 at 09:31:23PM +0100, pp yy wrote:\n\n> Maybe i missed something but i can't get relativepath when adding '-z'\n> \n> $ git --version\n> git version 2.17.1\n> $ git status -s test\n> ?? test\n> $ git status -s -z test\n> ?? plugins/git/test\n> $ git -c status.relativePaths=true status -s test\n> ?? test\n> $ git -c status.relativePaths=true status -s -z test\n> ?? plugins/git/test\n> \n> Bug or did i missed something ?\n\nI think it's a bug. At first I thought you were running up against the\nimplied porcelain output:\n\n  -z\n      Terminate entries with NUL, instead of LF. This implies the\n      --porcelain=v1 output format if no other format is given.\n\nbut you are explicitly saying \"-s\" (and running this in a terminal shows\nthat the result is colorized, which means we're triggering the short\nformat and not porcelain).\n\nAnd indeed, the \"-z\" code path seems to ignore the prefix entirely.\nSomething like this would fix it:\n\ndiff --git a/wt-status.c b/wt-status.c\nindex cc6f94504d..3a0e479407 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -1837,9 +1837,13 @@ static void wt_shortstatus_status(struct string_list_item *it,\n \t\tputchar(' ');\n \tputchar(' ');\n \tif (s->null_termination) {\n-\t\tfprintf(stdout, \"%s%c\", it->string, 0);\n+\t\tstruct strbuf scratch = STRBUF_INIT;\n+\t\tfprintf(stdout, \"%s%c\",\n+\t\t\trelative_path(it->string, s->prefix, &scratch), 0);\n \t\tif (d->rename_source)\n-\t\t\tfprintf(stdout, \"%s%c\", d->rename_source, 0);\n+\t\t\tfprintf(stdout, \"%s%c\",\n+\t\t\t\trelative_path(d->rename_source, s->prefix, &scratch), 0);\n+\t\tstrbuf_release(&scratch);\n \t} else {\n \t\tstruct strbuf onebuf = STRBUF_INIT;\n \t\tconst char *one;\n\nNow I do think it's a little weird to use \"-z\" with \"--short\" in the\nfirst place, since the whole point of \"-z\" is make something that can be\nparsed. And the whole point of \"--short\" versus \"--porcelain\" is that\nthe latter is stable and predictable (so it doesn't respect config at\nall).\n\nBut I guess I could imagine a use case where a script is taking in paths\nfrom the \"-z\" and then showing them to the user without further\nprocessing (and so it's convenient to get the relative path directly\nrather than computing them itself). I do wonder if there are any other\nsurprises in \"--short\" that might be lurking, though (IIRC, we do not\neven promise that the output will stay syntactically the same between\nversions; it could change to something completely different, or add new\nlines in future versions).\n\n-Peff\n"},{"id":"388440","messageId":"CAK60LiV_e=q33R20WJU=Hxrn6kKuXwehM+9j_8cmWX4krnmv2w@mail.gmail.com","threadId":"52463","inReplyTo":"20191216063425.GA2127604@coredump.intra.peff.net","subject":"Re: [bug] Adding -z to git status seems to disable relative path","fromName":"pp yy","fromEmail":"yoann.mac.donald@gmail.com","sentAt":"2019-12-18T14:04:06Z","receivedAt":"2019-12-18T14:04:21Z","isPatch":false,"sender":{"key":"yoann.mac.donald@gmail.com","avatar":null},"body":"Hi Peff\n\nEven without adding -s the option \"status.relativePaths\" isn't respected.\n$ git -c status.relativePaths=true status -z test\n?? plugins/git/test\n\nIt is explained in the man in fact.\nPorcelain v1 is applied when using\"-z\" and porcelain v1 explicitly state:\n\"\n1. The user’s color.status configuration is not respected; color will\nalways be off.\n2. The user’s status.relativePaths configuration is not respected;\npaths shown will always be relative to the repository root.\n\"\n\nWith this in mind, it seems impossible to have the same output as `git\n-c status.relativePaths=true -c color.status=always status -s test`\nbut with records separated by '\\0' (for scripting purpose), and that's\nwhat I was looking for :\n- list files status\n- separated by '\\0'\n- with colors\n\nRegards,\n\nLe lun. 16 déc. 2019 à 07:34, Jeff King <peff@peff.net> a écrit :\n>\n> On Sun, Dec 15, 2019 at 09:31:23PM +0100, pp yy wrote:\n>\n> > Maybe i missed something but i can't get relativepath when adding '-z'\n> >\n> > $ git --version\n> > git version 2.17.1\n> > $ git status -s test\n> > ?? test\n> > $ git status -s -z test\n> > ?? plugins/git/test\n> > $ git -c status.relativePaths=true status -s test\n> > ?? test\n> > $ git -c status.relativePaths=true status -s -z test\n> > ?? plugins/git/test\n> >\n> > Bug or did i missed something ?\n>\n> I think it's a bug. At first I thought you were running up against the\n> implied porcelain output:\n>\n>   -z\n>       Terminate entries with NUL, instead of LF. This implies the\n>       --porcelain=v1 output format if no other format is given.\n>\n> but you are explicitly saying \"-s\" (and running this in a terminal shows\n> that the result is colorized, which means we're triggering the short\n> format and not porcelain).\n>\n> And indeed, the \"-z\" code path seems to ignore the prefix entirely.\n> Something like this would fix it:\n>\n> diff --git a/wt-status.c b/wt-status.c\n> index cc6f94504d..3a0e479407 100644\n> --- a/wt-status.c\n> +++ b/wt-status.c\n> @@ -1837,9 +1837,13 @@ static void wt_shortstatus_status(struct string_list_item *it,\n>                 putchar(' ');\n>         putchar(' ');\n>         if (s->null_termination) {\n> -               fprintf(stdout, \"%s%c\", it->string, 0);\n> +               struct strbuf scratch = STRBUF_INIT;\n> +               fprintf(stdout, \"%s%c\",\n> +                       relative_path(it->string, s->prefix, &scratch), 0);\n>                 if (d->rename_source)\n> -                       fprintf(stdout, \"%s%c\", d->rename_source, 0);\n> +                       fprintf(stdout, \"%s%c\",\n> +                               relative_path(d->rename_source, s->prefix, &scratch), 0);\n> +               strbuf_release(&scratch);\n>         } else {\n>                 struct strbuf onebuf = STRBUF_INIT;\n>                 const char *one;\n>\n> Now I do think it's a little weird to use \"-z\" with \"--short\" in the\n> first place, since the whole point of \"-z\" is make something that can be\n> parsed. And the whole point of \"--short\" versus \"--porcelain\" is that\n> the latter is stable and predictable (so it doesn't respect config at\n> all).\n>\n> But I guess I could imagine a use case where a script is taking in paths\n> from the \"-z\" and then showing them to the user without further\n> processing (and so it's convenient to get the relative path directly\n> rather than computing them itself). I do wonder if there are any other\n> surprises in \"--short\" that might be lurking, though (IIRC, we do not\n> even promise that the output will stay syntactically the same between\n> versions; it could change to something completely different, or add new\n> lines in future versions).\n>\n> -Peff\n"}]}