home | list info | list archive | date index | thread index

Re: [SIGS-L3GO] Some git stuff

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__(*)__(*)________(*)(*)_________________



message navigation