> > Note that for the last three, you can also do stuff like this: > > > > git graph -SWiFi --author Alex Pilon --word-diff --word-diff-regex='\S' -w -- .profile.d > > Ok, so I just tried looking for all patches that affected a particular > function, and came up with no suitable search method. The -S option only > searches for patches that add or remove that symbol. Shoulda said -G. Sorry. > I'm left with limiting to a path and then grepping the output for that > function name and manually sorting through the output. > git blame can be more effective here, Nope, because we still don't have combined git log --patch and git blame. > but again, need to manually sort through the output and iteratively > git blame through commits mentioned in a function and that is limited > by missing commits that remove lines. -L :funcname:thefile or graph -Gfuncname --, kinda does it. Not sure if it deals well with renames. The problem with tracing functions is that unless the VCS understands the language, you're relying on the function name showing up in the patch proper, or context, the latter which git doesn't do. I've yet to see a semantic VCS, which git definitely isn't—stupid content tracker! Pun intended. Now add Rails excessive metaprogramming on top and… ugh. > Are you familiar with any search options that let me set a search > pattern for any match in the commit patch rather than just symbol > addition or removal? -G? > > Yeah, that's a mouthful. Use a shell with decent auto-completion, > > and have coworkers constantly throwing code your way that *warrants* > > this. It only takes <2 seconds to type anyway, which is far less > > than it would take for you to do in a GUI. > > Less than 2 seconds to type if you type at 420 words per minute I know you don't mean literally, but I definitely don't type even over 100 WPM. I just use tab a lot. > I think we all agreed at the table that if you use something often > enough, it can be far more efficient to use a text-based tool, but for > something that is used infrequently, it is more efficient to use the > gui simply due to the overhead of reading and understanding the > manpage. I know. Not disagreeing!