(bug): InterceptHandler corrupts call-site attribution for every stdlib-logging library.

[vivekkeshore]

Which interface did you use?

PyPI package

Repository URL (if public)

No response

Git host

GitHub (github.com)

Other Git host

No response

Repository visibility

private

Commit, branch, or tag

branch

Did you ingest the full repository or a subdirectory?

full repository

Operating system

Linux

Browser (Web UI only)

Not relevant (CLI / PyPI)

Other browser

No response

Gitingest version

0.3.1

Python version

3.12

Bug description

Summary

Once gitingest is imported, gitingest/utils/logging_config.py
runs configure_logging() at module scope and installs
InterceptHandler as the global stdlib logging handler for the
entire host process.

InterceptHandler.emit has a broken frame
walker that misattributes every intercepted record including
records emitted by other libraries (urllib3, httpx, boto3, loguru,
requests, the host application's own code, etc.) - to a fixed
stdlib internal location i.e. <logging:callHandlers:1762>,
instead of the line in the originating library that produced the log.

This is a silent failure: format strings still render, no exception
is raised, but every record across the entire host process loses
its actual call-site attribution.

Steps to reproduce

import os
os.environ.setdefault("LOG_LEVEL", "DEBUG")

import gitingest.utils.logging_config

import urllib3
try:
    urllib3.PoolManager(retries=False).request(
        "GET", "http://127.0.0.1:1/", timeout=0.3
    )
except Exception:
    pass

Expected behavior

2026-06-17 16:36:40.558 | DEBUG | urllib3.poolmanager:init:218 | Converted retries value: False -> Retry(total=False, connect=None, read=None, redirect=0, status=None)
2026-06-17 16:36:40.558 | DEBUG | urllib3.connectionpool:_get_conn:292 | Starting new HTTP connection (1): 127.0.0.1:1

Actual behavior

2026-06-17 16:36:18.413 | DEBUG | logging:callHandlers:1762 | Converted retries value: False -> Retry(total=False, connect=None, read=None, redirect=0, status=None)
2026-06-17 16:36:18.414 | DEBUG | logging:callHandlers:1762 | Starting new HTTP connection (1): 127.0.0.1:1

Additional context, logs, or screenshots

Secondary concern (optional follow-up)

configure_logging() runs unconditionally at the bottom of gitingest/utils/logging_config.py, so importing the module mutates the host process's stdlib logging configuration globally, and that causes this bug to impact every consumer.

Recommend configuring it behind an env var or an explicit gitingest.configure_logging() call.

[vivekkeshore]

Created PR - #587