← All posts

March 30, 2026·4 min read

Noise Filtering and Ticket Detection in gitglimpse

How gitglimpse automatically strips noise commits and extracts ticket IDs from branch names.

features internals developer-tools

Most of your commits don't matter for standups

Merge commits, lock file updates, linting fixes, dependency bumps — these are real work but they're noise in a standup. Nobody wants to read 'updated package-lock.json' in their daily summary. gitglimpse filters these automatically so your output only shows meaningful work.

How noise filtering works

Noise filtering is on by default. A commit is excluded if all of its changed files match noise patterns (lock files, minified assets, CI configs, cache files) or if its message matches known noise phrases (merge commits, lint fixes, format changes, version bumps). Importantly, commits that touch both noise files and real files are kept — only pure-noise commits are filtered.

bash
# Default — noise is filtered
glimpse standup
# Output: Filtered 3 noise commits (merges, formatting, dependencies)

# See everything including noise
glimpse standup --no-filter-noise

Ticket detection from branch names

If you follow a branch naming convention like feature/PROJ-123-description, gitglimpse automatically extracts the ticket ID and includes it in your output. It recognizes Jira-style IDs (PROJ-123), GitHub issues (#42), and similar patterns. No API integration needed — it's pure branch name parsing.

text
# Branch: feature/AUTH-42-jwt-refresh
# Output includes the ticket automatically:
  • Implemented JWT refresh flow (AUTH-42, feature/AUTH-42-jwt-refresh, ~1.5h)

Why this matters

  • Cleaner output without manual configuration — noise filtering is on by default.
  • Ticket IDs connect your code changes to business context without requiring Jira API integration.
  • Both features work in all modes — template, LLM, and JSON output.
  • Use --no-filter-noise when you need a complete picture of all commits.