{"thread":{"id":"36606","subject":"Is there any efficient way to track history of a piece of code?","startedAt":"2014-05-08T06:54:56Z","lastAt":"2014-05-09T06:56:36Z","messageCount":7,"participants":["Jianyu Zhan","Jeff King","David Kastrup","Chris Packham","Junio C Hamano","David Lang"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"240995","messageId":"CAHz2CGW4rRWzGMPxM1XsoYvrwrrddrxAr+AKAi5SdMx+3rBjNg@mail.gmail.com","threadId":"36606","inReplyTo":null,"subject":"Is there any efficient way to track history of a piece of code?","fromName":"Jianyu Zhan","fromEmail":"nasa4836@gmail.com","sentAt":"2014-05-08T06:54:56Z","receivedAt":"2014-05-08T06:54:56Z","isPatch":false,"sender":{"key":"nasa4836@gmail.com","avatar":"https://gravatar.com/avatar/f80b0399c04c6ca4b482c60a910f81c921a5aee6100120b1f6cee1da591fa181?d=mp&s=160"},"body":"Usually, a trivial change(like coding style fix) may bury a\noriginal change of the code, and thus git blame is of less\nhelp. And to address this situation, I have to do like this:\n\n git blame -s REF^ > temp\n\nto dig into the history recursively by hand, to find out\nthe original change.\n\nHere, REF is commit-id that git blame reports.\n\ngit log -L is a good alternative option, but sometimes it seems\ntoo cubersome, as I care only one line of code.\n\nIs there any current solution or suggestion?\n\nThanks,\nJianyu Zhan\n"},{"id":"240996","messageId":"20140508070051.GA4532@sigill.intra.peff.net","threadId":"36606","inReplyTo":"CAHz2CGW4rRWzGMPxM1XsoYvrwrrddrxAr+AKAi5SdMx+3rBjNg@mail.gmail.com","subject":"Re: Is there any efficient way to track history of a piece of code?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-05-08T07:00:51Z","receivedAt":"2014-05-08T07:00:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 08, 2014 at 02:54:56PM +0800, Jianyu Zhan wrote:\n\n> Usually, a trivial change(like coding style fix) may bury a\n> original change of the code, and thus git blame is of less\n> help. And to address this situation, I have to do like this:\n> \n> git blame -s REF^ > temp\n> \n> to dig into the history recursively by hand, to find out\n> the original change.\n> \n> Here, REF is commit-id that git blame reports.\n> \n> git log -L is a good alternative option, but sometimes it seems\n> too cubersome, as I care only one line of code.\n> \n> Is there any current solution or suggestion?\n\nTry \"tig blame\"[1]; from the blame view, the \",\" command will restart\nthe blame at REF^ automatically. If you don't mind a more graphical\ninterface, I think \"git gui blame\" can also reblame from the parent from\nthe right-click context menu.\n\n-Peff\n\n[1] http://jonas.nitro.dk/tig/\n"},{"id":"240997","messageId":"87bnv8rbp8.fsf@fencepost.gnu.org","threadId":"36606","inReplyTo":"CAHz2CGW4rRWzGMPxM1XsoYvrwrrddrxAr+AKAi5SdMx+3rBjNg@mail.gmail.com","subject":"Re: Is there any efficient way to track history of a piece of code?","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-05-08T07:06:43Z","receivedAt":"2014-05-08T07:06:43Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jianyu Zhan writes:\n\n> Usually, a trivial change(like coding style fix) may bury a\n> original change of the code, and thus git blame is of less\n> help. And to address this situation, I have to do like this:\n>\n> git blame -s REF^ > temp\n>\n> to dig into the history recursively by hand, to find out\n> the original change.\n>\n> Here, REF is commit-id that git blame reports.\n>\n> git log -L is a good alternative option, but sometimes it seems\n> too cubersome, as I care only one line of code.\n>\n> Is there any current solution or suggestion?\n\ngit blame -w\n\nmight help with a number of \"coding style fixes\".\n\n-- \nDavid Kastrup\n"},{"id":"240999","messageId":"CAHz2CGV6==abb0SrXOyqwumxEVLFnTtqe1Z4j2A7XcvJNuoAHw@mail.gmail.com","threadId":"36606","inReplyTo":"20140508070051.GA4532@sigill.intra.peff.net","subject":"Re: Is there any efficient way to track history of a piece of code?","fromName":"Jianyu Zhan","fromEmail":"nasa4836@gmail.com","sentAt":"2014-05-08T07:32:47Z","receivedAt":"2014-05-08T07:32:47Z","isPatch":false,"sender":{"key":"nasa4836@gmail.com","avatar":"https://gravatar.com/avatar/f80b0399c04c6ca4b482c60a910f81c921a5aee6100120b1f6cee1da591fa181?d=mp&s=160"},"body":"On Thu, May 8, 2014 at 3:00 PM, Jeff King wrote:\n> Try \"tig blame\"[1]; from the blame view, the \",\" command will restart\n> the blame at REF^ automatically. If you don't mind a more graphical\n> interface, I think \"git gui blame\" can also reblame from the parent from\n> the right-click context menu.\n\nThanks! It helps!\n\nHmm, but you know, we are cli people so we met git ;-)\n\nMy by-hand recursive digging history works for me and I've consider automate\nthis but failed since the pattern match to find the correct line of\ncode in each recursion\nis a big problem.\n\nThe root cause of this problem maybe that git is not semantic-aware. It if is,\nthen we could easily weed out the trivial-change or grammatical-change\nin git blame.\n\nHere a structural program comparison tool may be a direction.\nhttp://yinwang0.wordpress.com/2012/01/03/ydiff/\n\nThat being said, storing abstract syntax tree, instead of raw object in git.\nBut that goes too far...\n\nThanks,\nJianyu Zhan\n"},{"id":"241000","messageId":"536B33D5.7090301@gmail.com","threadId":"36606","inReplyTo":"CAHz2CGW4rRWzGMPxM1XsoYvrwrrddrxAr+AKAi5SdMx+3rBjNg@mail.gmail.com","subject":"Re: Is there any efficient way to track history of a piece of code?","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2014-05-08T07:35:49Z","receivedAt":"2014-05-08T07:35:49Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On 08/05/14 18:54, Jianyu Zhan wrote:\n> Usually, a trivial change(like coding style fix) may bury a\n> original change of the code, and thus git blame is of less\n> help. And to address this situation, I have to do like this:\n> \n> git blame -s REF^ > temp\n> \n> to dig into the history recursively by hand, to find out\n> the original change.\n> \n> Here, REF is commit-id that git blame reports.\n> \n> git log -L is a good alternative option, but sometimes it seems\n> too cubersome, as I care only one line of code.\n> \n> Is there any current solution or suggestion?\n> \n\nI use \"git gui blame\" for this all the time at $dayjob. If there aren't\ntoo many of these code clean ups then the eclipse git integration is\nalso handy for this but it will suffer from the same issues as git blame.\n"},{"id":"241017","messageId":"xmqq1tw43yrx.fsf@gitster.dls.corp.google.com","threadId":"36606","inReplyTo":"CAHz2CGV6==abb0SrXOyqwumxEVLFnTtqe1Z4j2A7XcvJNuoAHw@mail.gmail.com","subject":"Re: Is there any efficient way to track history of a piece of code?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-08T18:34:26Z","receivedAt":"2014-05-08T18:34:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jianyu Zhan writes:\n\n> On Thu, May 8, 2014 at 3:00 PM, Jeff King wrote:\n>> Try \"tig blame\"[1]; from the blame view, the \",\" command will restart\n>> the blame at REF^ automatically. If you don't mind a more graphical\n>> interface, I think \"git gui blame\" can also reblame from the parent from\n>> the right-click context menu.\n>\n> Thanks! It helps!\n>\n> Hmm, but you know, we are cli people so we met git ;-)\n>\n> My by-hand recursive digging history works for me and I've consider automate\n> this but failed since the pattern match to find the correct line of\n> code in each recursion\n> is a big problem.\n\nYes, by definition, there is no corresponding line in a version\nbehind the version shown in the blame output, so there needs some\nheuristics, such as \"assume the same line range\", \"find the\nbeginning and the end of the function definition that contains that\nline\", etc.\n"},{"id":"241105","messageId":"alpine.DEB.2.02.1405082354100.17457@nftneq.ynat.uz","threadId":"36606","inReplyTo":"CAHz2CGV6==abb0SrXOyqwumxEVLFnTtqe1Z4j2A7XcvJNuoAHw@mail.gmail.com","subject":"Re: Is there any efficient way to track history of a piece of code?","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2014-05-09T06:56:36Z","receivedAt":"2014-05-09T06:56:36Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 8 May 2014, Jianyu Zhan wrote:\n\n> That being said, storing abstract syntax tree, instead of raw object in git.\n> But that goes too far...\n\nwell, there are the clean/smudge filters, you can have it run everything through \na prettyprinter as it's checked in.\n\nwith a little effort, you could do something along the lines of git filterbranch \nthat could create a clone of a repo with all commits cleaned up.\n\nDavid Lang\n"}]}