threads / discuss / 36606

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

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

## tl;dr

7 messages between May 8, 2014 and May 9, 2014.

replies: 6people: 6as markdown or json

Jianyu Zhan· May 8, 2014, 06:54 UTC · lore

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

Jeff King· May 8, 2014, 07:00 UTC · re: Jianyu Zhan · lore

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

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

Show 15 quoted lines

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

Jianyu Zhan· May 8, 2014, 07:32 UTC · re: Jeff King · lore

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

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

Junio C Hamano· May 8, 2014, 18:34 UTC · re: Jianyu Zhan · lore

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

Jianyu Zhan <nasa4836@gmail.com> writes:

Show 14 quoted lines

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

David Lang· May 9, 2014, 06:56 UTC · re: Jianyu Zhan · lore

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

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

David Kastrup· May 8, 2014, 07:06 UTC · re: Jianyu Zhan · lore

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

Jianyu Zhan <nasa4836@gmail.com> writes:

Show 15 quoted lines

> 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

Chris Packham· May 8, 2014, 07:35 UTC · re: Jianyu Zhan · lore

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

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

Show 16 quoted lines

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