Bisect, Blame, Pickaxe Search, Merge Bases, and Repository Forensics: Configuration, Design Choices, and Tradeoffs

1. Forensic tooling needs policy because “convenient” can become misleading

Bisect, blame, and pickaxe are read/search mechanisms, but teams decide how tests classify revisions, which mechanical commits blame may ignore, how long history remains available, and where incident evidence is stored. Good policy makes those assumptions visible rather than hiding them in one engineer's workstation.

2. A shared .git-blame-ignore-revs file can document mechanical revisions

A common convention is to commit a repository file named .git-blame-ignore-revs containing full object IDs of approved formatting/mechanical commits, one per line with optional comments.

# Repository-wide formatting pass approved by maintainers
<full-object-id-for-formatting-commit>

The file is ordinary project content. Git does not automatically assume this filename; users/tools can pass --ignore-revs-file or configure blame.ignoreRevsFile.

3. Configure ignore-revision blame deliberately

git config --local blame.ignoreRevsFile .git-blame-ignore-revs
git config --show-origin --show-scope --get blame.ignoreRevsFile
git blame -L 1,20 -- path/to/file

A tracked ignore file can travel with clones, but the local config setting itself does not become a commit. A team can document bootstrap instructions or tool settings. Do not silently hide revisions without review: an “ignored” formatting commit can still contain a behavioral mistake.

4. Mark reattributed or unblamable lines when ambiguity matters

git -c blame.markIgnoredLines=true \
    -c blame.markUnblamableLines=true \
    blame --ignore-revs-file .git-blame-ignore-revs -- path/to/file

These markers make it visible when attribution passed through ignored revisions or could not be reconstructed cleanly. That is more honest than presenting adjusted blame as perfect provenance.

5. Treat the bisect test command as a versioned incident artifact

The test oracle should define input, environment prerequisites, classification threshold, and exit codes. For bisect run, current Git's contract is:

• 0 = good/old;
• 1 through 127 except 125 = bad/new;
• 125 = untestable/skip;
• other error conditions abort the run.

Because this contract controls the search, preserve the exact script/version used in the incident report.

6. A good bisect oracle must be monotonic enough for the searched interval

Classic regression bisect assumes there is a meaningful transition from good to bad along the searched ancestry. Flaky tests, external service outages, nondeterministic clocks, changing dependencies, or a bug that appears/disappears multiple times can violate that model.

Before automation, run the oracle repeatedly at both endpoints. If results fluctuate, stabilize the environment or narrow the question before trusting binary search.

7. Reserve skip for genuinely untestable revisions

Older commits may fail to build because toolchains changed. Exit 125 or git bisect skip is appropriate when the behavioral question cannot be evaluated. Marking inconvenient revisions as “bad” biases the answer; skipping too much can leave several adjacent candidates instead of one provable culprit.

8. Forensics require history availability

A depth-limited clone, aggressively pruned object store, deleted refs, or rewritten public history can remove evidence your incident procedure expects. Define which environments retain full history and release/deployment refs. A fast CI checkout can be shallow while a forensic/release mirror preserves complete history.

9. History rewrite policy should preserve a mapping when incidents reference old IDs

If a legitimate cleanup/rewrite changes commit IDs, retain an authorized mapping, release artifact provenance, signed records, or archived bundle/clone as policy permits. Otherwise an old incident report may name objects that no longer exist in the current published graph.

10. Author/committer clocks are metadata, not causal order

git show --no-patch --format=fuller <commit>
git log --graph --format='%H %P %aI %cI %s' --all

Author time can reflect when work was originally authored; committer time can change during rebases/cherry-picks. Clock skew is possible. Parent OIDs define the graph relationship, so forensic claims such as “X descended from Y” should come from ancestry commands, not date sorting.

11. Preserve incident notes outside mutable bisect checkout state

During bisect, Git repeatedly checks out historical snapshots. A notes file stored only as an uncommitted path inside the worktree risks conflicts or accidental loss. Keep live investigation notes in an external incident system, separate directory, or deliberately committed evidence repository.

printf "incident_id=INC-204\n" > ../INC-204-evidence.txt
git rev-parse HEAD >> ../INC-204-evidence.txt
git bisect log >> ../INC-204-evidence.txt

12. Configuration scope and precedence

git config --list --show-origin --show-scope | grep -E 'blame\.|diff\.|core\.abbrev'

The grep is POSIX-shell specific; PowerShell can use Select-String. Blame display/ignore defaults may differ by scope. Command-line options should be spelled out in incident commands when reproducibility matters rather than relying on a hidden global config.

13. Platform and shell considerations that materially affect forensic reproducibility

• Test scripts need shell/runtime availability on every candidate revision/environment.
• Line-ending conversion can affect text tests; define whether the oracle reads repository blobs or working-tree files.
• Path case behavior can vary by filesystem; use exact Git paths and explicit pathspec intent.
• Quote regex/pickaxe arguments so the active shell does not transform them.
• Credential/server differences matter if tests contact remote dependencies; prefer isolated local tests for bisect.

14. Git evidence versus hosting-platform evidence

Core Git knows commits, parents, refs, diffs, and author/committer metadata. Review approvals, issue discussions, CI logs, deployment records, and repository permissions belong to hosting/CI systems. A production investigation may correlate both, but it should label which claim came from which system.

15. Decision table — choose the evidence path

16. Knowledge check

17. Summary

Team forensic quality depends on policy around blame-ignore revisions, deterministic bisect exit contracts, complete history retention, graph-first chronology, and durable incident notes. These controls make the same Git query reproducible across people and environments.

Authoritative references

• git-bisect
• git-blame
• git-config