Jeff King <p...@peff.net> writes: > On Mon, Jan 22, 2018 at 10:22:21PM -0500, Aleksey Bykov wrote: > >> I am a code reviewer, I have a situation in GIT: >> >> - before: a.txt >> >> Then a developer decided to split the content of a.txt into 2 files >> and add a few changes all in one commit: >> >> - after: b.txt + few changes and c.txt + few changes >> ... > For seeing which line came from where, you might try "git blame -C", > which will cross file boundaries looking for the source of lines. > ... > And finally, if you're going to do a lot with "git blame", I'd look into > the "tig" tool as a prettier interface. You should be able to do "tig > blame -C ..." in the same way.
All excellent guides. "blame" is good at explaining where things came from, but not as good at explaining, starting from an old state, where things went. "blame --reverse" does a decent job within the constraints its output format has, but not quite ideal.
