It does not accept input standard input, but as command line arguments. You would think | basename would work, but no. ( man sort and man uniq) What about file names without paths? xargs basename I have used this for as long as I can remember. Who wants duplicate paths? Not you, not me! Oh hey look, they are sorted too! Enjoy. Get rid of that stupid leading commit hash sed "s/*://" A source.Īnother useful note that belongs here: You can throw in -i or -ignore-case to be case insensitive. Fixed String?Īs for -F, well, it just means use a fixed string instead a regex for pattern interpretation. Instead of showing every matched line, show only the names of files that containīlockquote Is your pattern: A. I hate Bash, so why do I keep using it? Dissection Get file names/paths onlyĪny of the following options mean the same ( git-rep documentation): Enjoy using these Bash snippets for as much agony as they caused to me. This second command is useful for BFG, because it only accept file names and not repo-relative/system-absolute paths. Unique, sorted, filenames (not paths): # Get all unique filenames matching 'password' Git grep -F -files-with-matches 'password' $revision | cat | sed "s/*://"ī. Relative, unique, sorted, paths: # Get all unique filepaths of files matching 'password' It just gets the file paths so that you can feed them into one of the two tools I just mentioned. This is useful in combination with BFG (Git filter branch - not to be confused with git-filter-branch) and git-filter-repo.
A common use-case is to display diff lines with that search term in commits since and including a given commit - 3b5ab0f2a1 in this example - like so: $ git log 3b5ab0f2a1^. This can then be piped to grep to isolate the output just to display commit diff lines with that search term. This will show the commits containing the search terms, but if you want to see the actual changes in those commits instead you can use -patch: $ git log -G"searchTerm" -patch While git log -G"frotz\(nitfol" will show this commit, git log -S"frotz\(nitfol" -pickaxe-regex will not (because the number of occurrences of that string did not change).
To illustrate the difference between -S -pickaxe-regex and -G, consider a commit with the following diff in the same file: + return frotz(nitfol, two->ptr, 1, 0) The git diff documentation has a nice explanation of the difference: This means that -S -pickaxe-regex and -G do not do exactly the same thing.-S finds commits where the number of occurrences of "word" changed, while -G finds commits where "word" appears in the diff.-G by default accepts a regex, while -S accepts a string, but it can be modified to accept regexes using the -pickaxe-regex.To look for differences whose added or removed line matches "word" (also commit contents). In modern Git there is also $ git log -Gword If you want to find all commits where "word" was added or removed in the file contents (to be more exact: where the number of occurrences of "word" changed), i.e., search the commit contents, use a so-called 'pickaxe' search with $ git log -Sword If you want to find all commits where the commit message contains a given word, use $ git log -grep=word
0 kommentar(er)
