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
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
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
Jianyu Zhan nasa4...@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
On Thu, May 8, 2014 at 3:00 PM, Jeff King p...@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
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
Jianyu Zhan nasa4...@gmail.com writes:
On Thu, May 8, 2014 at 3:00 PM, Jeff King p...@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
7 matches
Mail list logo
