Making git log ignore changes for certain paths

Navigating a large codebase often means sifting through a deluge of information, and your Git commit history is no exception. While git log is an indispensable tool for understanding project evolution, its output can become cluttered with changes to irrelevant files—think build artifacts, temporary logs, or auto-generated code. This noise can obscure critical changes, making it harder to track feature development or debug issues efficiently. Learning how to filter this output by making git log ignore changes for certain paths is a powerful skill that streamlines your development workflow, allowing you to focus on the meaningful contributions that shape your project.

For developers, a clean and focused commit history is paramount. It aids in code reviews, simplifies root cause analysis, and provides a clear narrative of a project’s journey. When your git log shows every minor tweak to a configuration file or an automatically generated stylesheet, it dilutes the signal-to-noise ratio. This article will guide you through practical methods to effectively prune your git log output, ensuring you only see the changes that matter most to your current task.

Why Filtering Your Git Log is Essential for Productivity

In any active development environment, repositories accumulate a variety of files that, while necessary for the build process or local setup, rarely contribute to the core logic or design of the application. These might include .env files, node_modules directories, compiled assets, or IDE-specific configuration files. When you run a standard git log command, changes to these paths are included by default, often creating an overwhelming and distracting stream of information.

This information overload can significantly impact productivity. Imagine trying to review a feature’s commit history, only to scroll past dozens of commits related to dependency updates or minor localization file changes. Such noise not only wastes time but also makes it harder to identify critical code changes, understand their context, and attribute responsibility using tools like git blame. A study by DORA (DevOps Research and Assessment) consistently highlights that developer productivity is linked to minimizing cognitive load and streamlining workflows, and a clean Git history contributes directly to this goal. By actively making git log ignore changes for certain paths, developers can reclaim their focus and accelerate their understanding of the codebase.

Furthermore, filtering your Git log is crucial for maintaining a healthy repository. It encourages developers to think about what constitutes a “meaningful change” versus a “utility change.” While all changes are part of the repository’s history, not all need to be front and center during every historical review. This selective view helps in code archaeology, allowing teams to quickly pinpoint when and why a particular piece of business logic was introduced or modified, without getting bogged down by extraneous details.

Practical Methods for Making git log Ignore Changes

Git offers several powerful ways to filter the output of git log directly from the command line, enabling you to specify exactly which files or directories you want to include or exclude from the history view. These methods are invaluable for making git log ignore changes for certain paths temporarily or for specific analysis tasks, providing immediate control over what you see.

The most straightforward approach involves specifying paths directly after the git log command. To view the log for a specific file or directory, simply append its path: git log path/to/file.js or git log path/to/directory/. This will show only the commits that touched the specified path. However, the real power comes from exclusion. To ignore changes for one or more paths, you can use the :(exclude) syntax or :(top) and then !. For example, to exclude all changes within a docs/ directory and a README.md file:

git log -- . ":!docs/" ":!README.md"

In this command, the – separates Git options from pathspec arguments, and . signifies “all files.” The “:!docs/” and “:!README.md” are pathspec patterns that explicitly tell Git to exclude any changes within the docs directory and the README.md file from the log output. This approach is highly flexible and can be combined with other git log options like –author, –since, or –grep to refine your search even further. Remember that pathspec patterns are relative to your current working directory unless specified otherwise.

Another useful technique for filtering involves the –diff-filter option, though it’s primarily used for filtering based on the type of change (Added, Deleted, Modified, etc.) rather than specific paths. However, when combined with path filtering, it can create very precise queries. For instance, if you want to see only modifications to source code files while ignoring specific directories:

git log --diff-filter=M -- . ":!node_modules/" ":!dist/"

This command would show only commits where files were modified, and those modified files are not located within node_modules or dist directories. This level of granularity is crucial for in-depth analysis of code changes, helping developers quickly identify relevant modifications without the distraction of build outputs or third-party library updates. This capability transforms a potentially overwhelming stream of data into a focused, actionable history.

Advanced Filtering with Git Aliases and Configuration -----------------------------------------------------

While command-line flags are effective for one-off queries, repeatedly typing long pathspec exclusions can become tedious. This is where Git’s powerful alias system comes into play, allowing you to define custom shorthand commands for complex git log operations. By leveraging aliases, you can permanently configure Git to streamline your workflow and simplify the process of making git log ignore changes for certain paths regularly.

To create a Git alias, you can use the git config command or directly edit your global or local .gitconfig file. For instance, if you frequently want to see the log of your application’s core logic, excluding common noise like documentation, build outputs, and configuration files, you could define an alias like this:

git config --global alias.corelog "log -- . ':!docs/' ':!README.md' ':!package-lock.json' ':!.log' ':!config/.yml'"

After setting this alias, a simple git corelog command would execute the much longer git log command with all the specified exclusions. This significantly reduces typing errors and ensures consistency across your team if shared. These aliases can be as complex as needed, combining path filters with pretty formats (e.g., –pretty=oneline), graph views (–graph), and other useful options. This is an excellent way to personalize your Git environment for maximum efficiency.

For more specific repository-level filtering, you might consider creating scripts or pre-commit hooks, though these affect how files are staged or committed, not directly how git log displays history. However, for managing files that Git should always treat as external or non-source, the .gitattributes file can be useful. For example, to tell GitHub’s Linguist to ignore a vendor directory for language statistics, you might use Question & Answer :

How can I make git log only show commits that changed files other than the ones I specify?

With git log, I can filter the commits I see to those that touch a given set of paths. What I want is to invert that filter so that only commits that touch paths other than the specified ones will be listed.

I can get what I want with

git log --format="%n/%n%H" --name-only | ~/filter-log.pl | git log --stdin --no-walk 

where filter-log.pl is:

#!/usr/bin/perl use strict; use warnings; $/ = "\n/\n"; <>; while (<>) { my ($commit, @files) = split /\n/, $_; if (grep { $_ && $_ !~ m[^(/$|.etckeeper$|lvm/(archive|backup)/)] } @files) { print "$commit\n"; } } 

except I want something somewhat more elegant than that.

Note that I am not asking how to make git ignore the files. These files should be tracked and committed. It’s just that, most of the time, I’m not interested in seeing them.

Related question: How to invert git log --grep=<pattern> or How to show Git logs that don’t match a pattern. It’s the same question except for commit messages rather than paths.

Forum discussion on this subject from 2008: Re: Excluding files from git-diff. This looked promising but the thread seems to have dried up.

It is implemented now (git 1.9/2.0, Q1 2014) with the introduction pathspec magic :(exclude) and its short form :! in commit ef79b1f and commit 1649612, by Nguyễn Thái Ngọc Duy (pclouds), documentation can be found here.

You now can log everything except a sub-folder content:

git log -- . ':(exclude)sub' git log -- . ':!sub' 

Or you can exclude specific elements within that sub-folder

• a specific file:

  git log -- . ':(exclude)sub/sub/file' git log -- . ':!sub/sub/file' 
  

• any given file within sub:

  git log -- . ':(exclude)sub/*file' git log -- . ':!sub/*file' git log -- . ':(exclude,glob)sub/*/file' 
  

You can make that exclusion case insensitive!

git log -- . ':(exclude,icase)SUB' 

As Kenny Evitt noted

Don’t forget to use single quotes or proper escaping in double quotes if you’re running git in a bash shell, e.g. ':!sub' or ":\!sub". Otherwise you will run into bash: ... event not found errors

---

Note: Git 2.13 (Q2 2017) adds a synonym ^ to !

See commit 859b7f1, commit 42ebeb9 (08 Feb 2017) by Linus Torvalds (torvalds).
^{(Merged by Junio C Hamano – gitster – in commit 015fba3, 27 Feb 2017)}

pathspec magic: add ‘^’ as alias for ‘!’

The choice of ‘!’ for a negative pathspec ends up not only not matching what we do for revisions, it’s also a horrible character for shell expansion since it needs quoting.

So add ‘^’ as an alternative alias for an excluding pathspec entry.

---

Note that, before Git 2.28 (Q3 2020), the use of negative pathspec, while collecting paths including untracked ones in the working tree, was broken.

See commit f1f061e (05 Jun 2020) by Elijah Newren (newren).
^{(Merged by Junio C Hamano – gitster – in commit 64efa11, 18 Jun 2020)}

dir: fix treatment of negated pathspecs

^{Reported-by: John Millikin
Signed-off-by: Elijah Newren}

do_match_pathspec() started life as match_pathspec_depth_1() and for correctness was only supposed to be called from match_pathspec_depth(). match_pathspec_depth() was later renamed to match_pathspec(), so the invariant we expect today is that do_match_pathspec() has no direct callers outside of match_pathspec().

Unfortunately, this intention was lost with the renames of the two functions, and additional calls to do_match_pathspec() were added in commits

• 75a6315f74 ("ls-files: add pathspec matching for submodules", 2016-10-07, Git v2.11.0-rc0 – merge listed in batch #11)
• 89a1f4aaf7 ("dir: if our pathspec might match files under a dir, recurse into it", 2019-09-17, Git v2.24.0-rc0).

Of course, do_match_pathspec() had an important advantge over match_pathspec() – match_pathspec() would hardcode flags to one of two values, and these new callers needed to pass some other value for flags.

Also, although calling do_match_pathspec() directly was incorrect, there likely wasn’t any difference in the observable end output, because the bug just meant that fill_diretory() would recurse into unneeded directories.

Since subsequent does-this-path-match checks on individual paths under the directory would cause those extra paths to be filtered out, the only difference from using the wrong function was unnecessary computation.

The second of those bad calls to do_match_pathspec() was involved – via either direct movement or via copying+editing – into a number of later refactors.

See commits

• 777b420347 ("dir: synchronize treat_leading_path() and read_directory_recursive()", 2019-12-19, Git v2.25.0-rc0 – merge)
• 8d92fb2927 ("dir: replace exponential algorithm with a linear one", 2020-04-01, Git v2.27.0-rc0 – merge listed in batch #5)
• 95c11ecc73 (“Fix error-prone fill_directory() API; make it only return matches”, 2020-04-01, Git v2.27.0-rc0 – merge listed in batch #5)

The last of those introduced the usage of do_match_pathspec() on an individual file, and thus resulted in individual paths being returned that shouldn’t be.

The problem with calling do_match_pathspec() instead of match_pathspec() is that any negated patterns such as :!unwanted_path will be ignored.

Add a new match_pathspec_with_flags() function to fulfill the needs of specifying special flags while still correctly checking negated patterns, add a big comment above do_match_pathspec() to prevent others from misusing it, and correct current callers of do_match_pathspec() to instead use either match_pathspec() or match_pathspec_with_flags().

One final note is that DO_MATCH_LEADING_PATHSPEC needs special consideration when working with DO_MATCH_EXCLUDE.

The point of DO_MATCH_LEADING_PATHSPEC is that if we have a pathspec like

*/Makefile 

and we are checking a directory path like

src/module/component 

that we want to consider it a match so that we recurse into the directory because it might have a file named Makefile somewhere below.

However, when we are using an exclusion pattern, i.e. we have a pathspec like

:(exclude)*/Makefile 

we do NOT want to say that a directory path like

src/module/component 

is a (negative) match.

While there might be a file named Makefile somewhere below that directory, there could also be other files and we cannot pre-emptively rule all the files under that directory out; we need to recurse and then check individual files.

Adjust the DO_MATCH_LEADING_PATHSPEC logic to only get activated for positive pathspecs.

---

Peter Mortensen adds in the comments:

But it is not sophisticated enough for more specific matching than matching any character(?).

For example, matching numbers in the path (example: “keyboards/keychron/c1_pro”, “keyboards/keychron/c2_pro”, “keyboards/keychron/c42_pro”, “keyboards/keychron/c821_pro”, etc.).

That it is far from something resembling regular expressions (if that is the case). Or is there an escape?

True: Git pathspecs do not support regular expressions directly, which means you cannot use them to match specific patterns like numbers or complex strings within paths in a manner similar to regular expressions.

For cases like Peter’s examples (keyboards/keychron/c1_pro, keyboards/keychron/c2_pro, keyboards/keychron/c42_pro, keyboards/keychron/c821_pro, etc.), the pathspec magic :(exclude) or :! allows for basic wildcard matching but does not offer the granularity of regular expressions.
You can exclude paths based on simple patterns like wildcards (* for any sequence of characters, ? for any single character) but not with the specificity that regular expressions provide (e.g., matching any path ending with a sequence of numbers followed by _pro).

If you need to filter Git logs based on more complex patterns that require regular expression-like matching, you would typically need to combine git log with other command-line tools that support regular expressions, such as grep or awk.
For example, to list commits affecting paths that match a specific pattern, you might first list all affected paths with git log --name-only, then filter those paths using grep with a regular expression.

However, for Peter’s specific use case of excluding paths, you could use a workaround by leveraging the shell’s capabilities or scripting. You would list all commits, then filter out commits that only affect the specified patterns. There is no direct escape within Git’s pathspec syntax that introduces regular expression capabilities.

Something like:

#!/bin/bash # Define the pattern to exclude. That uses extended regex for matching any 'keychron' directory followed by 'c', numbers, and '_pro' exclude_pattern='keyboards/keychron/c[0-9]+_pro' # Get a list of all commits, showing affected paths, then filter out commits that only modify paths matching the exclude pattern git log --all --name-only --format="%H" | \ awk '/^[0-9a-f]{40}$/{commit=$0; next} {print commit " " $0}' | \ grep -vE "$exclude_pattern" | \ cut -d' ' -f1 | \ uniq | \ while read commit; do git log -1 --format="%h %ad %s" --date=short $commit done