git debug traces (GIT_TRACE / GIT_TRANSFER_TRACE) can break git parsing

[bwalsh]

git debug traces (GIT_TRACE / GIT_TRANSFER_TRACE) can break git parsing

Problem summary When repository-level or environment debug tracing is enabled (for example via GIT_TRACE=1 and/or GIT_TRANSFER_TRACE=1), git prints additional debug lines to stdout/stderr. Our current implementation of lfs.IsLFSTracked, etc collects combined command output and naïvely parses it, which can cause the function to return incorrect results or silently ignore the intended value.
This manifests as intermittent failures or incorrect LFS detection when users or CI enable git trace output.

Where it happens
cmd/prepush/main.go
cmd/prepush/main_test.go
cmd/transferref/main.go
lfs/helpers.go
lfs/lfs_tracked.go
lfs/lfs_tracked_test.go
precommit_cache/helpers.go
tests/coverage-test.sh

Tests: previously observed failures in lfs package tests when GIT_TRACE is enabled

Reproduction steps

Run a command that calls IsLFSTracked (or run the lfs tests) with git tracing enabled:
export GIT_TRACE=1 GIT_TRANSFER_TRACE=1
go test ./lfs -run TestIsLFSTracked (or run the code path that calls IsLFSTracked)
Observe that the function may return the wrong boolean or tests may fail. Example noisy output added by git trace looks like:
trace: built-in: git ...
trace: exec: ...
data/file.dat: filter: lfs

Expected behavior IsLFSTracked should reliably return whether the requested path is tracked by LFS regardless of unrelated debug or trace lines from git.

Actual behavior Because stderr/debug lines are captured into the same buffer and parsing is done without filtering, debug lines can confuse the parsing logic:
The code used strings.Split(out.String(), ":") (or otherwise parsed the entire combined output) which may pick up the wrong line/field.
Non-path lines (debug lines, trace lines) can break parsing or cause the wrong value to be extracted.
Root cause

The implementation captures both stdout and stderr into the same buffer (cmd.Stdout = &out; cmd.Stderr = &out), so debug/tracing output that git normally writes to stderr or other channels is included with the intended stdout result.
Parsing assumes the whole buffer is exactly "path: filter: value" and applies an unguarded split. When extra lines are present, the split-based parsing becomes brittle.
In short: unfiltered combined output + naive parsing = fragile behavior when git emits extra lines.