Making 'git log' ignore changes for certain paths
tl;dr: shopt -s extglob && git log !(unwanted/glob|another/unwanted/glob)
If you're using Bash you should be able to use the extended globbing feature to get only the files you need:
$ cd -- "$(mktemp --directory)"
$ git init
Initialized empty Git repository in /tmp/tmp.cJm8k38G9y/.git/
$ mkdir aye bee
$ echo foo > aye/foo
$ git add aye/foo
$ git commit -m "First commit"
[master (root-commit) 46a028c] First commit
0 files changed
create mode 100644 aye/foo
$ echo foo > bee/foo
$ git add bee/foo
$ git commit -m "Second commit"
[master 30b3af2] Second commit
1 file changed, 1 insertion(+)
create mode 100644 bee/foo
$ shopt -s extglob
$ git log !(bee)
commit ec660acdb38ee288a9e771a2685fe3389bed01dd
Author: My Name <[email protected]>
Date: Wed Jun 5 10:58:45 2013 +0200
First commit
You can combine this with globstar
for recursive action.
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 abash
shell, e.g.':!sub'
or":\!sub"
. Otherwise you will run intobash: ... 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 pathspecsReported-by: John Millikin
Signed-off-by: Elijah Newren
do_match_pathspec()
started life asmatch_pathspec_depth_1()
and for correctness was only supposed to be called frommatch_pathspec_depth()
.match_pathspec_depth()
was later renamed tomatch_pathspec()
, so the invariant we expect today is thatdo_match_pathspec()
has no direct callers outside ofmatch_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 overmatch_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 thatfill_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
: synchronizetreat_leading_path()
andread_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-pronefill_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 ofmatch_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 abovedo_match_pathspec()
to prevent others from misusing it, and correct current callers ofdo_match_pathspec()
to instead use eithermatch_pathspec()
ormatch_pathspec_with_flags()
.One final note is that
DO_MATCH_LEADING_PATHSPEC
needs special consideration when working withDO_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 namedMakefile
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.