* [bug] Adding -z to git status seems to disable relative path
@ 2019-12-15 20:31 pp yy
2019-12-16 6:34 ` Jeff King
0 siblings, 1 reply; 3+ messages in thread
From: pp yy @ 2019-12-15 20:31 UTC (permalink / raw)
To: git
Hi,
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 ?
Regards,
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bug] Adding -z to git status seems to disable relative path
2019-12-15 20:31 [bug] Adding -z to git status seems to disable relative path pp yy
@ 2019-12-16 6:34 ` Jeff King
2019-12-18 14:04 ` pp yy
0 siblings, 1 reply; 3+ messages in thread
From: Jeff King @ 2019-12-16 6:34 UTC (permalink / raw)
To: pp yy; +Cc: git
On Sun, Dec 15, 2019 at 09:31:23PM +0100, pp yy wrote:
> 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
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [bug] Adding -z to git status seems to disable relative path
2019-12-16 6:34 ` Jeff King
@ 2019-12-18 14:04 ` pp yy
0 siblings, 0 replies; 3+ messages in thread
From: pp yy @ 2019-12-18 14:04 UTC (permalink / raw)
To: Jeff King; +Cc: git
Hi Peff
Even without adding -s the option "status.relativePaths" isn't respected.
$ git -c status.relativePaths=true status -z test
?? plugins/git/test
It is explained in the man in fact.
Porcelain v1 is applied when using"-z" and porcelain v1 explicitly state:
"
1. The user’s color.status configuration is not respected; color will
always be off.
2. The user’s status.relativePaths configuration is not respected;
paths shown will always be relative to the repository root.
"
With this in mind, it seems impossible to have the same output as `git
-c status.relativePaths=true -c color.status=always status -s test`
but with records separated by '\0' (for scripting purpose), and that's
what I was looking for :
- list files status
- separated by '\0'
- with colors
Regards,
Le lun. 16 déc. 2019 à 07:34, Jeff King <peff@peff.net> a écrit :
>
> On Sun, Dec 15, 2019 at 09:31:23PM +0100, pp yy wrote:
>
> > 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-12-18 14:04 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-15 20:31 [bug] Adding -z to git status seems to disable relative path pp yy
2019-12-16 6:34 ` Jeff King
2019-12-18 14:04 ` pp yy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).