From: Kousik Sanagavarapu <five231003@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Christian Couder <christian.couder@gmail.com>
Subject: Re: [PATCH] t6300: values containing ')' are broken in ref formats
Date: Wed, 6 Nov 2024 08:10:32 +0530 [thread overview]
Message-ID: <ZyrXIKU8Qn46Z0LF@five231003> (raw)
In-Reply-To: <xmqqikt1qhwt.fsf@gitster.g>
On Tue, Nov 05, 2024 at 05:18:10PM -0800, Junio C Hamano wrote:
> Kousik Sanagavarapu <five231003@gmail.com> writes:
>
> > Document that values containing ')' in formats are not parsed correctly
> > in ref-filter.
>
> The problem is probably lack of a way to quote such a closing
> parenthesis.
Yes correct. We currently don't have a way to quote such strings in
"value" of "%(atom:someparam=value)"
> > However formats having a '(' instead in "value" will parse correctly
> > because in a general format string we also mark start of the format by
> > making note of '%(' instead of just '('.
>
> So if you wanted to have a two-char sequence '%(' in value, you'd
> see a similar problem? If so, it is not quite a "bug" or "not
> parsed correctly"---it is "because there is no way to include
> closing ')' in the value (e.g., by quoting), you cannot write such a
> string in the value part".
>
> > This raises the question of what can be done to parse ')' in values of
> > the format correctly. It seems to me like a clean solution would
> > involve a huge refactoring involving a large portion of ref-filter but I
> > maybe wrong.
>
> Yes, so I wouldn't even call the current behaviour "bug". The
> language is merely "limited" and the user cannot express certain
> values with it at all.
>
>
> Having said that, I just tried this
>
> $ git for-each-ref --format='%28%(refname)%29' refs/heads/master
> (refs/heads/master)
>
> So, if there is anything that needs "fixing", wouldn't it be
> documentation?
>
> If I knew (or easily find out from "git for-each-ref --help") that
> hex escapes %XX can be used, I wouldn't have written any of what I
> said before "Having said that" in this response.
Hmm, but hex escapes do work as intended and the problem here is not the
')' outside the atom but within it. To be more clear, let's take
$ git for-each-ref --format="%(if:equals=refs/heads/step-1)start)%(refname)%(then)%(objectname:short)%(end)" refs/heads/
(Sorry for not wrapping the line above x<)
First let's notice the difference between what these two commands are
trying to do. Your command asks to print all the refs matching
"refs/heads/master" in the format of (%(refname)) and since we support
escaping literals in the form of %xx, where xx is the hexcode of the
literal to be escaped during the parsing of the format, this would
obviously work as intended.
Now let's come to my command. My command asks to print all the
abbreviated commit ids of the refs which compare equal to
"refs/heads/step-1)start" from all of "refs/heads/". Now here, since
ref-filter parses the format string by making note of '%(' and ')', it
accidentally thinks that I want to compare equality with
"refs/heads/step-1" instead of "refs/heads/step-1)start", which I
actually wanted. If my local repo contained both the "refs/heads/step1"
and "refs/heads/step1)start", wouldn't this be a bug?
So I do agree that it is a lack of quoting when entering the "value"
part of "%(atom:someparam=value)", but another part of me also thinks
that ref-filter should be intelligent enough while parsing the format
string to acknowledge where exactly the atom ends and which is the last
closing ')' and hence follows whatever I wrote below the "---" line,
till the script.
Also, I'm thinking the commit msg was not clear as it lead you (perhaps
someone else too when they visit this topic) to think about escape
literals while that not exactly is the problem I'm trying to get at.
Also if you think a change to the documentation would be more proper
than reflecting this with a test breakage, I'll do that. My intention
with the test was that - in the future if we parse the "value" correctly
then that commit would also include a
s/test_expect_failure/test_expect_success
change.
Thanks!
prev parent reply other threads:[~2024-11-06 2:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-05 18:41 [PATCH] t6300: values containing ')' are broken in ref formats Kousik Sanagavarapu
2024-11-06 1:18 ` Junio C Hamano
2024-11-06 2:25 ` Jeff King
2024-11-06 3:05 ` Junio C Hamano
2024-11-06 3:54 ` Kousik Sanagavarapu
2024-11-06 18:55 ` Jeff King
2024-11-07 2:34 ` Kousik Sanagavarapu
2024-11-06 18:51 ` Jeff King
2024-11-07 2:29 ` Kousik Sanagavarapu
2024-11-07 2:52 ` Junio C Hamano
2024-11-08 4:11 ` Kousik Sanagavarapu
2024-11-08 17:16 ` Jeff King
2024-11-08 18:12 ` Kousik Sanagavarapu
2024-11-06 2:40 ` Kousik Sanagavarapu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZyrXIKU8Qn46Z0LF@five231003 \
--to=five231003@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).