问题
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:
- Delete
colors.txt
Add
red.txt
with these contents:red
Add
green.txt
with these contents:green
Add
blue.txt
with these contents:blue
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
)?
回答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
回答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".
回答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.
来源:https://stackoverflow.com/questions/44935712/viewing-changes-to-deleted-files-in-git