From: Jeff King <peff@peff.net>
To: Jeff Hostetler <git@jeffhostetler.com>
Cc: Christian Hesse <mail@eworm.de>,
Junio C Hamano <gitster@pobox.com>,
Git Mailing List <git@vger.kernel.org>,
Jeff Hostetler <jeffhost@microsoft.com>,
"Jason A. Donenfeld" <Jason@zx2c4.com>
Subject: Re: cgit and global configuration
Date: Wed, 12 Jun 2019 15:08:46 -0400 [thread overview]
Message-ID: <20190612190845.GA14949@sigill.intra.peff.net> (raw)
In-Reply-To: <1cdb3444-fb39-66a4-fb27-01e1617e538a@jeffhostetler.com>
On Tue, Jun 11, 2019 at 04:22:32PM -0400, Jeff Hostetler wrote:
> As for going forward, I see 3 options:
>
> [1] update your tests to allow this. (I didn't dig thru your
> tests to see how extensive this might be.)
>
> [2] define your own version of common-main.c and link with it
> instead of git/common-main.c and delete the calls to trace2_*()
> in it.
>
> [3] define your own version of common-main.c and then call your
> prepare_repo_env() prior to trace2_initialize().
>
> Granted, I've only spent 15 minutes looking at your code, so
> I may be mistaken about several things, but I think those are
> your options.
After reading the original report, my instinct was that (2) or (3) is
probably the right way forward. We could make it a little easier for
them by splitting up common-main a bit into two parts:
- put the actual setup bits into a callable run_cmd_main() that ends
up in libgit.a
- make common-main.c a tiny shim that does:
int main(int argc, const char **argv)
{
return run_cmd_main(argc, argv);
}
And that makes it easy for them to replace just that shim with some
setup steps, ending in calling run_cmd_main().
All that said, it sounds like cgit doesn't actually need to do any setup
that _must_ be in-process; it's just modifying state like environment
variables that is passed down to children.
So I think it would also be sufficient to simply wrap it with something
like:
#!/bin/sh
unset HOME
unset XDG_CONFIG_HOME
exec /path/to/cgit "$@"
But maybe there are reasons not to want the complexity of a wrapper.
-Peff
next prev parent reply other threads:[~2019-06-12 19:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-11 15:04 cgit and global configuration Christian Hesse
2019-06-11 19:55 ` Junio C Hamano
2019-06-11 20:22 ` Jeff Hostetler
2019-06-12 19:08 ` Jeff King [this message]
2019-10-25 16:10 ` Christian Hesse
2019-10-25 21:24 ` Jeff King
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=20190612190845.GA14949@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=Jason@zx2c4.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jeffhost@microsoft.com \
--cc=mail@eworm.de \
/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.