Is there any efficient way to track history of a piece of code?

Usually, a trivial change(like coding style fix) may bury a
original change of the code, and thus git blame is of less
help. And to address this situation, I have to do like this:

   git blame -s REF^ <file-in-question> > temp

to dig into the history recursively by hand, to find out
the original change.

Here, REF is commit-id that git blame reports.

git log -L is a good alternative option, but sometimes it seems
too cubersome, as I care only one line of code.

Is there any current solution or suggestion?

Thanks,
Jianyu Zhan

On Thu, May 08, 2014 at 02:54:56PM +0800, Jianyu Zhan wrote:

Usually, a trivial change(like coding style fix) may bury a
original change of the code, and thus git blame is of less
help. And to address this situation, I have to do like this:

   git blame -s REF^ <file-in-question> > temp

to dig into the history recursively by hand, to find out
the original change.

Here, REF is commit-id that git blame reports.

git log -L is a good alternative option, but sometimes it seems
too cubersome, as I care only one line of code.

Is there any current solution or suggestion?

Try "tig blame"[1]; from the blame view, the "," command will restart
the blame at REF^ automatically.  If you don't mind a more graphical
interface, I think "git gui blame" can also reblame from the parent from
the right-click context menu.

-Peff

[1] http://jonas.nitro.dk/tig/

On Thu, May 8, 2014 at 3:00 PM, Jeff King [off-list ref] wrote:

Try "tig blame"[1]; from the blame view, the "," command will restart
the blame at REF^ automatically.  If you don't mind a more graphical
interface, I think "git gui blame" can also reblame from the parent from
the right-click context menu.

Thanks! It helps!

Hmm, but you know, we are cli people so we met git ;-)

My by-hand recursive digging history works for me and I've consider automate
this but failed since the pattern match to find the correct line of
code in each recursion
is a big problem.

The root cause of this problem maybe that git is not semantic-aware. It if is,
then we could easily weed out the trivial-change or grammatical-change
in git blame.

Here a structural program comparison tool may be a direction.
http://yinwang0.wordpress.com/2012/01/03/ydiff/

That being said, storing abstract syntax tree, instead of raw object in git.
But that goes too far...

Thanks,
Jianyu Zhan

On 08/05/14 18:54, Jianyu Zhan wrote:

Usually, a trivial change(like coding style fix) may bury a
original change of the code, and thus git blame is of less
help. And to address this situation, I have to do like this:

   git blame -s REF^ <file-in-question> > temp

to dig into the history recursively by hand, to find out
the original change.

Here, REF is commit-id that git blame reports.

git log -L is a good alternative option, but sometimes it seems
too cubersome, as I care only one line of code.

Is there any current solution or suggestion?

I use "git gui blame" for this all the time at $dayjob. If there aren't
too many of these code clean ups then the eclipse git integration is
also handy for this but it will suffer from the same issues as git blame.

On Thu, 8 May 2014, Jianyu Zhan wrote:

That being said, storing abstract syntax tree, instead of raw object in git.
But that goes too far...

well, there are the clean/smudge filters, you can have it run everything through 
a prettyprinter as it's checked in.

with a little effort, you could do something along the lines of git filterbranch 
that could create a clone of a repo with all commits cleaned up.

David Lang