v3.19.0: Line-Level Git Filtering: Surgical Precision 🎯
6
Publication Date: 23/03/2026
Author: Anas Chakroun
8-9 minutes
You edit a file with 48 logs. You add 2 new debug statements. You enable "Git Changes" filter to clean up before committing. The tree shows all 50 logs, including the 48 you didn't touch.
That noise made the filter almost useless for its primary purpose: identifying which debug logs you're about to commit. v3.19.0 fixes this with surgical precision.
The Problem: File-Level Filtering
The original git integration (v3.15.0) tracked which files had changes. When you enabled the filter, it showed all logs from those files. While technically accurate, this approach had limited practical value.
⚠️ Real-World Scenario
You're working on userService.ts, a file that already has 48 console.log statements from past debugging sessions.
Today, you add just 2 new debug logs while fixing a validation bug. You stage the file with git add and enable the "Git Changes" filter, expecting to see only your 2 new logs.
Instead, the tree shows all 50 logs. You can't tell which 2 are yours without manually scanning every single one.
This limited its usefulness. The filter became a "show me files I touched" feature instead of a "show me what I just added" feature, making pre-commit cleanup challenging.
The Fix: Line-Level Precision
v3.19.0 doesn't just track which files changed. It tracks which specific lines changed and only shows logs within those line ranges when you enable the "Git Changes" filter from the Turbo Pro panel.
🎯 How It Works Now
1. Parse Git Diffs: When you stage/unstage files, Turbo Pro fetches the git diff via VS Code's Git API
2. Extract Line Ranges: Parse unified diff format to identify which lines were added/modified
3. Filter Logs: Show only logs whose line numbers fall within changed ranges
4. Auto-Update: Refresh instantly when git status changes
Same scenario, new behavior:
✅ The Fix in Action
Same file, same 48 existing logs, same 2 new logs on lines 85-92. You stage the file with git add.
Turbo Pro parses the git diff, extracts the changed line range (85-92), and stores it internally.
Enable the "Git Changes" filter → the tree shows ONLY the 2 logs within lines 85-92. Clean, precise, exactly what you need.
- NewGit integration - filter logs by changed files only (staged, modified, untracked)
- Workspace-wide tree view: see every log across all files
- Instant search: find any log by content in seconds
- Smart filtering: filter logs from the tree view using multiple criteria
- Mass cleanup: comment, uncomment or delete multiple logs at once
- Multi-language: JavaScript, TypeScript, PHP support
One-time payment. Lifetime access. Get all current Pro features plus any future updates and improvements. Works on up to 5 machines.
Technical Implementation
This required three new components working together: a git diff parser, enhanced change tracking, and precise filtering logic.
1. Git Diff Parser
Parses unified diff format (the @@ markers you see in git diffs) to extract changed line ranges. It tracks additions in the new file, ignores deletions, and merges adjacent ranges for performance. The output is a simple array of line ranges like [{ start: 12, end: 13 }].
2. Enhanced Git Change Tracker
Extended to track both files and line ranges. For each changed file, it fetches the git diff, parses the line ranges, and stores them in a map alongside the file set.
Handles edge cases gracefully:
- Untracked files: No HEAD to diff against → show all logs (graceful fallback)
- Binary files: Diff fails → show all logs (no line ranges available)
- External git operations: Files modified via
git reset/checkout→ tracked separately, re-scanned to sync state
3. Line-Level Log Filtering
For each log in the tree, checks if its line number falls within any of the changed line ranges. Handles the conversion between VS Code's 0-indexed line numbers and git's 1-indexed format. Only shows logs that are within changed ranges.
Performance Optimizations
Three optimizations ensure this doesn't slow down the extension with large diffs or many files:
- Adjacent Range Merging: Consecutive line ranges like
[5,5], [6,6], [7,7]are merged into[5,7]to reduce iteration cost during filtering - Conditional Tree Refresh: When git filter is active, save events skip unnecessary tree refreshes (race condition fix); git tracker handles refresh with fresh line ranges
- Event Emission Only When Changed: Change tracker only fires events when files or line ranges actually change, not on every git state update
Comprehensive Testing
This release adds 82 new unit tests covering every component and edge case:
📊 Test Coverage Breakdown
- parseDiffLineRanges: 50+ tests covering empty diffs, single/multiple hunks, only additions, only deletions, mixed changes, markers, real-world git diffs → 100% coverage (statements, branches, functions, lines)
- GitChangeTracker: 21 tests for initialization, repository discovery, file change detection, line range tracking, change detection, event emission → 85% statements, 77% branches, 90% functions, 87% lines
- filterLogsByMethod: 11 new tests for line range filtering, index conversion (0-based ↔ 1-based), boundary conditions, no ranges fallback → 96% statements, 96% branches, 100% functions, 96% lines
Real-World Impact
This transforms the "Git Changes" filter from a file-level tracking feature into a precision cleanup tool.
- Pre-commit cleanup is now effortless: Stage your changes, enable the filter, see exactly which logs you're about to push
- Code review preparation: Quickly verify you didn't leave debug logs in your new code
- Refactoring sessions: Focus only on logs you added during the refactor, not the 100 existing ones
- Large file modifications: No more scrolling through 50+ logs to find the 2 you just added
v3.19.0 takes git integration from "nice to have" to "essential for clean commits". File-level tracking was the foundation. Line-level precision is what makes it useful.
This is the release that makes "never commit debug logs" an automatic outcome, not a manual checklist item.