From: Kousik Sanagavarapu <five231003@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>,
git@vger.kernel.org,
Christian Couder <christian.couder@gmail.com>
Subject: Re: [PATCH] t6300: values containing ')' are broken in ref formats
Date: Fri, 8 Nov 2024 09:41:03 +0530 [thread overview]
Message-ID: <Zy2PV+yywkS64D1p@five231003> (raw)
In-Reply-To: <xmqqo72rvjqk.fsf@gitster.g>
On Thu, Nov 07, 2024 at 11:52:03AM +0900, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> [...]
>
> The implementation may be a bit involved, but shouldn't be too bad.
>
> When .str is an empty string in if_atom_handler(), we can follow
> what the current code does. If .str is not empty, allocate a new
> stack element in order to parse the .str to its end by pointing
> .at_end of the new stack element to a new handler (call it
> if_cond_handler()), and pass the if_then_else structure it allocated
> as .at_end_data to it.
>
> And in the if_cond_handler(), grab the cur->output and overwrite the
> .str member with it (while being careful to avoid leaks). At the
> end of the if_cond_handler(), pass control to if_then_else_handler()
> by arranging the if_then_else_handler is called, imitating the way
> how if_atom_handler() passes control to if_then_else_handler() in
> the current code.
>
> Then things like
>
> %(if:equals=%(upstream:lstrip=3))%(refname:short)%(then)...
So if I understand correctly, we grab the .str and operate on it so that
we expand the atom within it and then do the comparision.
This seems nice, but there is a problem. Since we always look for the
first occurring ')' in our format string to indicate the end of the atom,
we end up with
.str = %(upstream:lstrip=3
(the call chain is
verify_ref_format() -> parse_ref_filter_atom() -> if_atom_parser()
)
Since we have now left out a ')', this ')' gets appended to our output
buf, which would also show up in cur->output when we do the comparision
in then_atom_handler(). For example, in this case our cur->output would
be ")master" instead of "master" after we get the value of
%(refname:short), meaning our comparision always fails.
next prev parent reply other threads:[~2024-11-08 4:11 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 [this message]
2024-11-08 17:16 ` Jeff King
2024-11-08 18:12 ` Kousik Sanagavarapu
2024-11-06 2:40 ` Kousik Sanagavarapu
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=Zy2PV+yywkS64D1p@five231003 \
--to=five231003@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.