My favorite way to do it is with git log's -G option (added in version 1.7.4). The accepted answer was still searching for text after ≈10 minutes of me running it, whereas this one gives results after ≈4 seconds □♂️. The -pickaxe-regex option allows you to use extended POSIX regex instead of searching for a string.Įxample (from git log): git log -S"frotz\(nitfol" -pickaxe-regexĪs Rob commented, this search is case-sensitive - he opened a follow-up question on how to search case-insensitive.Įxecuting a git log -G -branches -all (the -G is same as -S but for regexes) does same thing as the accepted one ( git grep $(git rev-list -all)), but it soooo much faster! It usually means "revisions where you added or removed line with 'Foo'". This looks for differences that introduce or remove an instance of. Then -S ( pickaxe) was ported to git log in May 2006 with Git 1.4.0-rc1. S (named pickaxe) comes originally from a git diff option (Git v0.99, May 2005). See Git history - find lost line by keyword for more. To search for Foo: git log -SFoo - path_containing_change You should use the pickaxe ( -S) option of git log. Search all revisions between rev1 and rev2 for text matching regular expression regexp: git grep $(git rev-list. Search all revisions for text matching regular expression regexp: git grep $(git rev-list -all) Search working tree for changed lines of text matching pattern: git diff -unified=0 | grep Search working tree for files that have lines of text matching regular expression regexp1 and lines of text matching regular expression regexp2: git grep -l -all-match -e -e Search working tree for lines of text matching regular expression regexp1 and regexp2, reporting file paths only: git grep -l -e -and -e Search working tree for lines of text matching regular expression regexp1 or regexp2: git grep -e -e Search working tree for text matching regular expression regexp: git grep Here are some other useful ways of searching your source: Just imagine the following scenario: grep might find the same on other files which are contained in the same revision returned by rev-list (even if there was no change to that file on that revision). The reason for passing the path in both commands is because rev-list will return the revisions list where all the changes to lib/util happened, but also you need to pass to grep so that it will only search in lib/util. This will grep through all your commit text for regexp. If you want to limit the search to some subtree (for instance, "lib/util"), you will need to pass that to the rev-list subcommand and grep as well: git grep $(git rev-list -all - lib/util) - lib/util Git rev-list -all | xargs git grep will work if you run into an "Argument list too long" error. To search for commit content (i.e., actual lines of source, as opposed to commit messages and the like), you need to do: git grep $(git rev-list -all)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |