Something not mentioned is

git log -S"pattern"

This is useful for searching diffs. If your repo is small this is quite fast. However for large repos, it can be slow which is why I use my own diffs indexer. Below is a screenshot of what my diffs search looks like.

http://screenshots.gitsense.com/diffs-search.html

For most people, git log -S should work fine but my solution is targeted for enterprise, which is why I went my own route.

I wrote the article.

The article includes git log -G"pattern". git log -S"string" it limited to a string.

As well, -S<string> only shows patches where the diff changes the number of occurrences of <string>. Thus if a patch both adds and removes <string>, it won't be shown by -S. -G<pattern> will show any patches where <pattern> occurs in the diff at all.

Sorry about that. I just looked for -S as that's all that I ever use for performance reasons, but you are correct as you do mention a diff search example.

Very interesting. If you haven't tried grepping the files in your git repository (as opposed to using regular `grep` or your editor's search function, which doesn't ignore files outside version control), it's surprisingly powerful.

I wasn't aware that `git grep` was as customizable as is shown in the article. I tend to use `ag` (the silver searcher) instead of regular grep, which besides being fast produces nice colored output. Here's a `zsh` function I put into my ~/.zshrc which allows me to apply ag only to files tracked by git: https://gist.github.com/pesterhazy/9294048

I'm also using `ag` over `ack` and `grep` as it seems to combine the speed of grep with the features of ack.

In fact, the author used `git grep` to benchmark against: http://geoff.greer.fm/2011/12/27/the-silver-searcher-better-...

It looks like the author used BSD grep on OSX (despite linking to FSF) which explains the dogshit performance of grep. If you use a mac install grep from Homebrew with the `--default-names` option.

Using full blown Perl regular expressions is easier for Debian/Ubunt users: Just use them!

I have never understood why --with-pcre is not the default in Homebrew, --without-pcre should be the option.

Speaking of Homebrew – is there a way to get it installed on Mac OS without an Apple ID?

I got this fancy shiny Macbook (with a broken keyboard, but who cares…) from IT and it might actually make sense to use it sometimes, but I don’t really want to go through the hassle of registering with Apple just to get a recent-ish Bash, git etc. The instructions on the website seem to require Xcode to be installed, which seems to only be available via iTunes.

Yes you'll need an Apple ID to get XCode and other Apple updates. Very annoying but for quite a few software programs, there's not much choice than to go through the dreadful App Store application.

I am sorry but I have no idea. You don't need an Apple ID to install Debian;)

Yeah, but running it in a Virtualbox is not quite the same and I don’t think IT would let me install it directly on the HDD (even though all the workstations run Ubuntu).

Is something as elementary as `git grep` really front page HN material?

It gives at least one non-obvious thing - grouping searches like ack. It gives a number of practical examples, explains git diff-index, and a number of other git commands that aren't that well known. Then it explains how to integrate ack into your editor.

Does that perhaps answer your question?

I tried the above on one project large enough that git complained about the argument size, so if you run into this problem, do something like:

   git rev-list --all | (while read rev; do git grep -e <regexp> $rev; done)

The '--all' argument tells rev-list to emit the history of every single ref. You probably only want a branch. Also, this is a job for xargs:

   git rev-list master | xargs git grep -e <regexp>

Slightly tangential, but related: on windows, Agent Ransack is an awesome program for searching through files/directories. It has a great UI, is quite fast, and has all the features you could want (regexes on filename and/or file contents, search history, etc). It is really helpful for doing quick lookups to see where methods/classes/variables are being used in the codebase.

are ninjas well known for being good at searching?

Are ninjas known for being good at software engineering? Are Rockstars, for that matter? I think these terms have replaced "like a pro" and other such turns-of-phrase that were once common.

git-grep is something you only learn about when you work on a large codebase, and something you never stop using afterwards.

By which they mean, "Leaving the repository owner bleeding out from a cut carotid artery, never knowing what happened to them?"

Didn't we make a pact to stop using "ninja" and "rock star"? Excepting, of course, an interviewee who a) arrives in the conference room via the air ducts while the the interview's back is turned, or b) who snorts lines of coke off the whiteboard tray and then smashes holes in the sheetrock walls with a Fender Stratocaster.

My first thought reading the title was also "isn't this 'ninja' thing a bit old by now?", then I saw the date - 2012.

Ah, thanks. That's helpful.

Why hello, speedy downvoter! Care to make your criticism explicit?

Looks like you got down voted by a ninja. Heh