(bug): Gitingest config overrides host logging globally

[yogur]

Which interface did you use?

PyPI package

Repository URL (if public)

No response

Git host

Other (specify below)

Other Git host

local directory

Repository visibility

private

Commit, branch, or tag

Select one...

Did you ingest the full repository or a subdirectory?

subdirectory

Operating system

Linux

Browser (Web UI only)

Select one...

Other browser

No response

Gitingest version

0.3.1

Python version

3.12.3

Bug description

Importing gitingest changes my app’s global logging behavior and formatting. This happens because gitingest/utils/logging_config.py calls configure_logging() at import time, which:

• Calls logger.remove() (removes all existing loguru sinks)
• Installs its own sinks and an stdlib intercept handler: logging.basicConfig(handlers=[InterceptHandler()], level=0, force=True)
• Iterates all loggers to clear handlers and set propagate=True for each

Result: my app’s logging policy (levels, handlers, formatting) is replaced, and internal gitingest logs appear even when I want WARNING+ for third‑party libs.

Why this is a problem

• Breaks host app formatting and policy (e.g., structlog config).
• Makes it impossible to suppress third‑party INFO/DEBUG while keeping app DEBUG.
• Surprising side effects from a library import.

Steps to reproduce

1) Configure an app that uses structlog or standard logging. The app sets its own loggers at INFO level (or DEBUG with a flag), and all third‑party internal libs at WARNING+. It also defines its own custom formatter.
2) Now `import gitingest`
3) Observe log level and formatting changes overridden by gitingest.

Expected behavior

• Library should not configure global logging on import.
• Library should not intercept stdlib or force‑reset handlers for unrelated loggers.
• Library logging should be scoped to gitingest and be opt‑in.

Actual behavior

Importing gitingest globally reconfigures logging and surfaces its internal logs irrespective of the host app’s settings.

Additional context, logs, or screenshots

Suggestions

• Do not execute configure_logging() on import in gitingest/utils/logging_config.py. Expose it, but let applications call it explicitly.
• Avoid logging.basicConfig(..., force=True) and avoid setting a global InterceptHandler.
• Do not clear handlers for all loggers or flip propagate across the entire logger tree.
• Scope any configuration to logging.getLogger("gitingest") only.
• Provide a kill‑switch env var (e.g., GITINGEST_DISABLE_LOGGING_CONFIG=1) and default to disabled; document how apps can opt‑in if they want your loguru setup.
• If interception is needed for a specific use case, consider making it an explicit, documented helper (e.g., configure_logging(intercept_stdlib=True)) rather than the default.