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

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

[Jianyu Zhan]

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

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

[Jeff King]

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/

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

[David Kastrup]

Jianyu Zhan <nasa4836@gmail.com> writes:

> 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?

git blame -w

might help with a number of "coding style fixes".

-- 
David Kastrup

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

[Jianyu Zhan]

On Thu, May 8, 2014 at 3:00 PM, Jeff King <peff@peff.net> 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

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

[Chris Packham]

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.

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

[Junio C Hamano]

Jianyu Zhan <nasa4836@gmail.com> writes:

> On Thu, May 8, 2014 at 3:00 PM, Jeff King <peff@peff.net> 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.

Yes, by definition, there is no corresponding line in a version
behind the version shown in the blame output, so there needs some
heuristics, such as "assume the same line range", "find the
beginning and the end of the function definition that contains that
line", etc.

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

[David Lang]

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