在git中查看对已删除文件的更改

Question

Let's say that when I branch off from master, there's a file colors.txt on the master branch of my repo with these contents:

red
green
blue
yellow

I then branch off into my-branch , in which I make the following changes:

1. Delete colors.txt

2. Add red.txt with these contents:

    red 

3. Add green.txt with these contents:

    green 

4. Add blue.txt with these contents:

    blue 

5. Add yellow.txt with these contents:

    yellow 

Now, there have been some changes on master that I need, so I want to merge. However, someone has also changed colors.txt to:

red
green
blue
yellow
orange
purple

During my merge, the only information I get is that I deleted the file colors.txt , so how can I see the changes that have been to the file on master so I can appropriately resolve the conflict (in this case, by adding the files orange.txt and purple.txt )?

Answer 1

You can show all changes done to that file on master using this command:

git diff HEAD...master -- colors.txt

This should lead to this output in your case:

red
green
blue
yellow
+orange
+purple

Using three dots for git diff will show the changes of all commits which are parents of the second referenced commit but not of the first referenced commit. Therefore, using this you will see all changes which would be merged if the file had not been deleted.

By using -- colors.txt the changes shown by git diff are limited to that file.

A more generic version of that command would be

git diff HEAD...MERGE_HEAD -- colors.txt

MERGE_HEAD is always set to the merged commit, thus it can replace the merged branch name. Using this you could even set up an alias to reuse this command:

git config --global alias.merge-diff-theirs "diff HEAD...MERGE_HEAD"

Afterwards you can just do

git merge-diff-theirs -- colors.txt

Answer 2

Tricky scenario, right? I think the best you can try to do is find out "when" color.txt was deleted. If you weren't merging, I'd say: use a bisect to find out when the file disappeared so you can see what happened but you are merging so that's no good. git blame --reverse can help somewhat by telling you when was the last time the file was present on your working tree. git log --name-status -- <file-path> can also help you see when the file disappeared (and why, through a nicely written revision comment, right?). I would tell you to give difflame a testdrive (A tool I worked on that by blending blame and diff output would be able to tell you the exact revision where the lines were deleted) but I think that because the file was deleted altogether, it will break.. not sure though. Here's the link just in case: https://github.com/eantoranz/difflame . Now... if you are able to find out on which revision the file was deleted, you might find out why it was deleted and you should figure out that you have to create a file for the new color that was added to color.txt while keeping color.txt deleted so that the merge is "complete".

Answer 3

Okay, I tested the following:

• Checkout a new branch color-test
• Add orange/purple to existing colors.txt and commit
• Switch back to "master"
• Delete colors.txt
• Try merge, which fails

For me, git diff colors-test.. -- colors.txt gives the following output:

-red
-green
-blue
-yellow
-orange
-purple

where color-test is the branch where I added orange/purple and ..(nothing) indicates the HEAD . This might be okay when the file is that small, however, a full diff might be better.

To find out, in which commit you deleted the file, you can try something like

git log --name-status -- colors.txt

and you'll find a commit with D colors.txt which is the commit in which you deleted the file, in my case the short hash is e1bb165 . You might want to diff against the commit before that

git diff colors-test..e1bb165~1 -- colors.txt

which gives me

green
blue
yellow
-orange
-purple

When you pass the -R switch to git diff , you will get + instead of - (the inputs are reversed).

Hope that helps.