On Thu, Dec 27, 2012 at 11:36:13PM -0800, Eric W. Biederman wrote: > git-ls-files | xargs fgrep 'struct f2fs_inode' > > That returns instantly and tells me where to look. If you can do an > instant brute force search what is the point of an index?
Not if you're using a lame-ass laptop with a rotating disk: $ time git ls-files | xargs grep -E 'struct mce\W*{' arch/x86/include/uapi/asm/mce.h:struct mce { arch/x86/kernel/cpu/mcheck/mce.c: if (!final || memcmp(m, final, sizeof(struct mce))) { real 2m48.415s user 0m2.388s sys 0m15.668s What I've grown accustomed to is cscope with a prior find run on the kernel source tree to create a custom cscope.files which cscope uses to index and then using vim bindings in cscope so that if, for example, the cursor is on a function call, executing a keyboard shortcut opens the definition of that function in another vim tab. I.e., a thin IDE done right. > My experience with gui editors is that they always hide something I > need to see, or my code is just strange enough (say having asm file, > or supporting multiple architectures) that the tools get horribly > confused. That's true, then I tend to use another xterm with tabbed vim showing additional files. Btw, git ls-files assumes a source file is tracked by git and in the seldom case where you're adding new, yet untracked files, that won't work. So probably a mixed approach of cscope in one window and grep + editor in another would cover all bases. For a newbie who wants to only browse the code, cscope should be enough for starters, I'd say. Thanks. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/