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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
