Making 'git log' ignore changes for certain paths

Question

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;

$/ = "
/
";
<>;

while (<>) {
    my ($commit, @files) = split /
/, $_;

    if (grep { $_ && $_ !~ m[^(/$|.etckeeper$|lvm/(archive|backup)/)] } @files) {
        print "$commit
";
    }
}

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.

Answer 1

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) will add 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) and 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), and 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.