Re: The original file that was split in 2 other files, is there a way in git to see what went where?

Hello,

My problem:

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

Is there an easy way to see:

1. what came to b from a?
2 .what came to c from a?
3. all extra changes apart from just moving stuff?

A specific command would help a lot.

A certain policy/workflow that prevents from problem like this (when there is no way to visually diff the changes) would also help.

https://stackoverflow.com/questions/48350398/the-original-file-that-was-split-in-2-other-files-is-there-a-way-in-git-to-see

Thanks, Aleksey Bykov

On Mon, Jan 22, 2018 at 7:22 PM, Aleksey Bykov <aleksey.bykov@gmail.com> wrote:

One way to do this is to use "--color-moved" - it will tell you what in b.txt and c.txt was moved and what wasn't (although it won't tell you from where). This was introduced recently, I think in 2.15.

On Mon, Jan 22, 2018 at 10:22:21PM -0500, Aleksey Bykov wrote:

Jonathan suggested the new "--color-moved", which I second as a good way of seeing what was moved, and which lines were changed.

For seeing which line came from where, you might try "git blame -C", which will cross file boundaries looking for the source of lines.

For instance, here's a case in git where some code was moved:

  git blame -C ae563542bf10fa8c33abd2a354e4b28aca4264d7 revision.c

You can see which lines are new to the file, and which ones were moved from elsewhere.

If you want to simplify the "noise" of seeing the actual origin of each line, you can ask blame not to go further back. Like:

  commit=ae563542bf10fa8c33abd2a354e4b28aca4264d7
  git blame -b -C $commit^..$commit revision.c

That will leave the commit id blank for every line that wasn't touched as part of the commit (or if you had a whole series of commits, replace "$commit^" with the parent of the series).

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.

-Peff

Jeff King <peff@peff.net> writes:

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.