All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Kousik Sanagavarapu <five231003@gmail.com>,
	 git@vger.kernel.org,
	Christian Couder <christian.couder@gmail.com>
Subject: Re: [PATCH] t6300: values containing ')' are broken in ref formats
Date: Thu, 07 Nov 2024 11:52:03 +0900	[thread overview]
Message-ID: <xmqqo72rvjqk.fsf@gitster.g> (raw)
In-Reply-To: <20241106185102.GA880133@coredump.intra.peff.net> (Jeff King's message of "Wed, 6 Nov 2024 13:51:02 -0500")

Jeff King <peff@peff.net> writes:

> who is doing:
>
>   %(if:equals=%%foo)
>
> to match the literal "%%foo" will be broken if we change that. They are
> not doing anything wrong; that is the only way to make it work now.

Ah, you're absolutely right.  Unescaping would start breaking them.

> I wouldn't go so far as to call the current behavior a bug. It's
> just...not very flexible. I also think it is unlikely that anybody would
> care in practice (though I find matching refs with ")" in them already a
> bit far-fetched).

100% agreed.  For that matter, I find "if:equals=%%foo" equally
implausible.

> If we wanted to be extra careful, we could introduce a variant of
> "equals" that indicates that it will be expanded before comparison.  Or
> even an extra tag, like:
>
>   %(if:expand:equals=%%foo)

Surely, but if nobody screams, I am tempted to suggest fixing the
equals/notequals---we do not have to be bug-to-bug compatible with a
buggy old implementation. After all, we do expand the string being
inspected that appears between %(if) and %(then).  I do not think of
a good excuse for us to limit the string that it gets compared with
to literals.

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)...

would work as expected ;-)

  parent reply	other threads:[~2024-11-07  2:52 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 [this message]
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

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=xmqqo72rvjqk.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=christian.couder@gmail.com \
    --cc=five231003@gmail.com \
    --cc=git@vger.kernel.org \
    --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.