Git Debug Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow — decide "borrow the pattern," not "adopt the package." This is a Symfony2 bundle; it cannot be installed into a Laravel codebase and is archived with zero dependents. The PM decision it enables is whether to replicate its idea — surfacing deployed Git branch/commit/dirty-state in the developer's existing debug surface — as a small first-party Laravel Debugbar collector rather than pulling in a niche third-party dev-tool plugin.
• Developer-experience roadmap prioritization. The problem it addresses ("which commit is actually running on staging, and is the working tree dirty?") burns real engineering time per sprint across multi-environment delivery. If your team logs repeated version-confusion or wrong-branch debugging incidents, this is a justified small-scope DX investment — one sprint-week, not a quarter.
• Release-traceability feature framing. The bundle is a low-fidelity version of higher-value product work: Sentry/New Relic release tags, an X-App-Commit response header, a /version or /health endpoint, and build-time commit injection from CI. Use this package as the argument for investing in the production-grade version, which pays off in incident response and QA sign-off, not just local ergonomics.
• Environment-scoping and information-disclosure policy. Reinforces a standing rule: any tool exposing branch names, commit hashes, or remote URLs (which can embed legacy CI credentials) must be hard-gated behind APP_DEBUG and APP_ENV !== 'production', with URL redaction. Treat it as environment-scoped instrumentation, never a global feature.
• Tooling consolidation. 22 stars, 0 dependents, archived, Symfony2-only: a data point against accumulating niche third-party dev-tool plugins and for a small, owned internal diagnostics convention with a documented ADR.

When to Consider This Package

Consider it only as a design input, and only when:

• You are on legacy Symfony 2.x (not Symfony 3+/Flex, not Laravel) with a frozen dependency set on an archived branch and need a throwaway read-only toolbar panel.
• You accept zero upstream support, no security patches, no PHP 8 compatibility guarantees, and the operational requirement that the web user can read .git and shell_exec/proc_open is permitted.
• You are explicitly evaluating the concept for reimplementation — in which case read the collector for its field list and service wiring, then write your own.

Look elsewhere — and plan to build in-house — when:

• You are on Laravel (the stated context). Symfony bundle conventions, the event system, and the DataCollectorInterface contract differ; there is no adapter to barryvdh/laravel-debugbar.
• You need maintained, supported tooling. Archived: yes and Dependents: 0 mean no bug fixes, no CVE response, no validation against modern PHP/Laravel.
• You need release auditing in production — use CI-injected build metadata, Sentry release tags, and a version endpoint instead; a debug toolbar is the wrong vehicle.
• You deploy artifacts/tarballs where .git is absent, or your container policy disables process execution — the bundle's core mechanism degrades there.

Recommended path: a ~one-week internal laravel-git-debugbar package — a single DataCollectorInterface collector plus a service provider gated on config('app.debug') — reading a CI-injected commit SHA, batched into one git status --porcelain=v2 --branch call via Symfony\Component\Process\Process, failing silently when Git or .git is unavailable.

How to Pitch It (Stakeholders)

To executives: A narrow, low-cost developer-productivity improvement — not a platform dependency. The underlying pain is real: engineers sometimes can't tell which code version is deployed to a given environment, which burns debugging time and can invalidate QA sign-off. We are not adopting this specific package: it is archived, unmaintained, tied to an obsolete framework, and has 22 stars and zero dependents — the maintenance and security risk is disproportionate to the benefit. Instead we'll implement the same capability natively in roughly one engineering week, restricted to development and staging, and pair it with the release-tagging we already need for incident response. Cost: negligible; risk: low provided production exposure is blocked; payoff: faster environment triage and cleaner release verification.

To engineering: The idea is sound and cheap to replicate; the artifact is not. Do not add it as a dependency — Symfony2-only, archived, no patch path, no compatible collector contract on Laravel 10–12 / PHP 8.2+. Build a small internal collector registered via a provider guarded by APP_DEBUG, reading a commit SHA injected at build time (defaulting to "unknown"), rendering branch, short SHA, tag, dirty flag, and a redacted remote URL. Harden the failure modes: no git on PATH, missing .git in artifact deploys, detached HEAD in CI, disabled shell_exec/open_basedir, and Git's "dubious ownership" refusal in Docker bind mounts — degrade to "Git: unavailable," never throw inside a collector. Record the build-vs-adopt decision in a short ADR on day one so the archived-upstream lineage doesn't need re-litigating. If you only want the reference implementation, read the upstream collector for its field list; budget half a day for the spike, one to two days for the hardened version with tests.