Symfony Debug Toolbar Git Laravel Package

Product Decisions This Supports

• Build vs. buy: build. This is a ~50–100 line dev-only convenience (read git log -1 --format=..., expose to the debug toolbar). The package is Symfony-bundle-specific, four+ years without a release, and has zero dependents — there is no maintenance dividend to buy into. Reproducing the behavior internally, or folding it into an existing debugbar collector, is cheaper than the vendor review, compatibility testing, and eventual fork.
• Feature scoping: developer diagnostics, not user-facing product. The value is "which commit is this environment actually running?" surfaced at the moment a developer is already staring at the profiler. Useful for triage; does not move a product metric, so it should not compete with roadmap capacity.
• Roadmap placement: opportunistic DX polish. A candidate for a maintenance sprint or a "quality of life" backlog item, not a planned initiative. If the team already runs a debugbar, it is a small collector addition; if not, the feature does not justify introducing one.
• Use cases worth capturing in the ticket: confirming that staging/prod matches the tagged release after a deploy; attaching commit SHA and branch to bug reports and QA notes; distinguishing "the fix isn't deployed" from "the fix is broken" during support triage; spotting a dirty working tree or detached HEAD on a shared dev environment.
• Ecosystem decision that actually matters: this package is Symfony-only, so for a Laravel codebase the real decision is which debugbar/telemetry surface owns this information (Laravel Debugbar collector, Ignition/Telescope context, or an /health or /version endpoint). That is the decision to make; this repository is only the reference implementation.

When to Consider This Package

• Narrow fit: a Symfony 3.x/4.x application still on PHP 7.x, already using the Symfony debug toolbar, where "which commit am I running" is repeatedly asked and nothing else supplies it. Even then, read the source before installing — the logic is trivial enough to vendor a copy into the repo.
• Do not adopt if the codebase is Laravel, Laminas, or framework-agnostic — this is a Symfony bundle and will not register outside a Symfony kernel.
• Do not adopt if you are on Symfony 5/6/7 or PHP 8.x. A 2018 release predates those and should be assumed incompatible until proven otherwise; dev-only packages still enter your lockfile and your dependency-update surface.
• Do not adopt if the organization requires maintained dependencies, even in require-dev. Stale, unmaintained code carries supply-chain and review overhead disproportionate to its benefit, and the "0 dependents / 30 stars" signal means no upstream fixes are coming.
• Look elsewhere if the underlying need is release traceability across environments: a build-time injected version constant, a /version endpoint, or CI-driven metadata is more reliable than reading .git at runtime — which also fails in container images that exclude the repository.
• Look elsewhere if the need is observability rather than local debugging: OpenTelemetry resource attributes or a deployment marker in your APM covers this better than a toolbar panel.

How to Pitch It (Stakeholders)

Executive summary: We evaluated kendrick/symfony-debug-toolbar-git, which displays the current Git commit in the Symfony debug toolbar. It supports a genuinely useful habit — knowing exactly which commit an environment is running during debugging and support triage — but the package itself is not the right vehicle. It is Symfony-only and therefore inapplicable to our Laravel stack, has had no release since January 2018, and has no downstream users. Recommendation: do not add the dependency. Instead, take the idea, not the code: spend roughly one engineer-day adding commit SHA and branch to the developer surfaces we already own (debugbar collector plus a small /version endpoint), with the commit baked in at build time so it still works in containers without a .git directory. This delivers the diagnostic value permanently, keeps us off an unmaintained dependency, and works regardless of framework. Ask: approve the one-day task in the next maintenance sprint and close the package evaluation.