From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Ryan Hendrickson via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org,
Ryan Hendrickson <ryan.hendrickson@alum.mit.edu>
Subject: Re: [PATCH v3] http: do not ignore proxy path
Date: Thu, 01 Aug 2024 07:40:31 -0700 [thread overview]
Message-ID: <xmqqfrroxq5c.fsf@gitster.g> (raw)
In-Reply-To: <20240801054523.GA621899@coredump.intra.peff.net> (Jeff King's message of "Thu, 1 Aug 2024 01:45:23 -0400")
Jeff King <peff@peff.net> writes:
> I think Ryan picked up this approach from my earlier mail. And the
> reason I suggested doing it this way is that the prereq test has an
> important side effect: it creates the socket and starts the proxy
> server!
Ah, OK.
> I think lazy prereqs only make sense when their only output is the
> yes/no of whether we match the prereq. And then we don't care when or
> how often they are evaluated.
Once the prereq test is attempted the result is cached (that's the
whole point of lazy prereq mechanism) so we won't see multiple sock
proxies spawned.
> I do think things would work, assuming the
> proxy server then can serve multiple tests. It just feels weird, and
> doing it more like the git-daemon/http tests made more sense to me
> (though those ones do not even do their work inside an expect block).
OK. That's fine. It is probably not a good fit for the pattern.
> If we did it in a lazy prereq I think you'd need to munge the path, as
> the lazy prereq operates in a throwaway directory (so the %30.sock would
> get removed before we can use it in the next test).
True.
next prev parent reply other threads:[~2024-08-01 14:40 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-26 15:52 [PATCH] http: do not ignore proxy path Ryan Hendrickson via GitGitGadget
2024-07-26 16:29 ` Junio C Hamano
2024-07-26 17:12 ` Ryan Hendrickson
2024-07-26 17:45 ` Junio C Hamano
2024-07-26 21:11 ` Jeff King
2024-07-26 22:43 ` Ryan Hendrickson
2024-07-29 19:31 ` Jeff King
2024-07-27 6:44 ` [PATCH v2] " Ryan Hendrickson via GitGitGadget
2024-07-29 20:09 ` Jeff King
2024-07-31 15:33 ` Ryan Hendrickson
2024-07-31 16:01 ` [PATCH v3] " Ryan Hendrickson via GitGitGadget
2024-07-31 22:24 ` Junio C Hamano
2024-08-01 3:44 ` Ryan Hendrickson
2024-08-01 5:21 ` Junio C Hamano
2024-08-01 5:45 ` Jeff King
2024-08-01 14:40 ` Junio C Hamano [this message]
2024-08-01 5:22 ` [PATCH v4] " Ryan Hendrickson via GitGitGadget
2024-08-01 6:04 ` Jeff King
2024-08-01 17:04 ` Junio C Hamano
2024-08-02 5:20 ` [PATCH v5] " Ryan Hendrickson via GitGitGadget
2024-08-02 15:52 ` Junio C Hamano
2024-08-02 16:43 ` Ryan Hendrickson
2024-08-02 17:10 ` Junio C Hamano
2024-08-02 18:03 ` Ryan Hendrickson
2024-08-02 19:28 ` Junio C Hamano
2024-08-02 19:39 ` Ryan Hendrickson
2024-08-02 21:13 ` Junio C Hamano
2024-08-02 21:26 ` Ryan Hendrickson
2024-08-02 21:43 ` Junio C Hamano
2024-08-02 21:47 ` Junio C Hamano
2024-08-02 22:14 ` Ryan Hendrickson
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=xmqqfrroxq5c.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=peff@peff.net \
--cc=ryan.hendrickson@alum.mit.edu \
/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).