On 16/05/15, Alex Pilon wrote: > > > 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. Interesting. I was wondering why I didn't find it before... I find that option on wheezy, but not on RHEL6... I currently need it only on the RHEL6 machine, so even more impetus to re-install that machine to RHEL7. > > 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. And -L nor git graph even exist on wheezy, so I should upgrade to jessie... > 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. Well, you type a whole lot faster than I can think... > > 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! slainte mhath, RGB -- Richard Guy Briggs -- ~\ -- ~\ <hpv.tricolour.ca> <www.TriColour.ca> -- \___ o \@ @ Ride yer bike! Ottawa, ON, CANADA -- Lo_>__M__\\/\%__\\/\% Vote! -- <greenparty.ca>_____GTVS6#790__(*)__(*)________(*)(*)_________________