7 ms·
Search a git repo
- octo_t 13y agoare ninjas well known for being good at searching?
- amirmc 13y agoAre 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.
- loevborg 13y agoVery 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 https://gist.github.com/pesterhazy/9294048
- sdfjkl 13y agoI'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-than-ack/ http://geoff.greer.fm/2011/12/27/the-silver-searcher-better-...
- dfc 13y agoIt 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.
- wpietri 13y agoBy 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.
- wpietri 13y agoWhy hello, speedy downvoter! Care to make your criticism explicit?
- goldenkey 13y agoLooks like you got down voted by a ninja. Heh
- laurent123456 13y agoMy first thought reading the title was also "isn't this 'ninja' thing a bit old by now?", then I saw the date - 2012.
- wpietri 13y agoAh, thanks. That's helpful.
- dfc 13y agoUsing 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.
- claudius 13y agoSpeaking 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.
- dfc 13y agoI am sorry but I have no idea. You don't need an Apple ID to install Debian;)
- claudius 13y agoYeah, 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).
- laurent123456 13y agoYes 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.
- sdesol 13y agoSomething 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 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.
- travisjeffery 13y agoI wrote the article. The article includes git log -G"pattern". git log -S"string" it limited to a string.
- sdesol 13y agoSorry 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.
- js2 13y agoAs 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.
- rafekett 13y agogit-grep is something you only learn about when you work on a large codebase, and something you never stop using afterwards.
- js2 13y agoI 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>
- nilved 13y agoIs something as elementary as `git grep` really front page HN material?
- chris_wot 13y agoIt 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?
- dwaltrip 13y agoSlightly 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.