Re: cgit and global configuration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux