Git "missing" commit

Question

I am in a situation where some changes made to the branches of the trait are not reflected in master, although this branch was merged with it. I do not understand why. For simplicity, suppose this commit hash "A" and the file "file" is modified

This can be best illustrated by the following commands:

$ git checkout master $ git branch --contains A * master feature_branch $ git log file | grep A (no output) $ git checkout feature_branch $ git log file | grep A A 

Can someone explain what is going on here? More importantly, is there something that can be done to prevent this from happening again?

EDIT:

As mentioned by several people, the following: commit:

 $ git checkout master $ git log --follow file | grep A A 

But the fact is that the file has not been renamed. So this doesn’t fully explain things, either ..

Answer 1

You are the victim of an evil merger.

Here's how to play it

 git init testrepo cd testrepo touch initial git add initial git commit -m 'initial commit' git checkout -b feature_branch echo "A" >> file git add file git commit -m 'file committed' git checkout master 

Now do an interactive merge as if merge conflicts have occurred

 git merge --no-commit --no-ff feature_branch 

and move the file file (merge of evil).

 testrepo (master|MERGING) git mv file someOtherFile git commit 

Now you will see that the branch wizard contains a commit (in my case 9469682 ) in which the file file was entered

  git branch --contains 9469682 feature_branch * master 

But git log does not display it because it was moved

  git log -- file (no output) 

Using

 git log --follow -- file 

and the commit will appear again.

Also keep in mind that merging can do more evil. If the contents of file also changed a lot than èven git log --follow will not detect it because of the renaming threshold.

In this case, use git log --follow --find-renames= to set the renaming threshold.

If you create a diff, detect and report renames for each commit. For the following rename files while going through the history, see --follow. If n is specified, this is the threshold value for the similarity index (i.e., the number of additions / exceptions compared to file size). For example, -M90% means that git should treat the delete / add pair as a rename if more than 90% of the file has not changed. An unsigned% number should be read as a fraction with a decimal point in front of it. Ie, -M5 becomes 0.5 and thus coincides with -M50%. Similarly, -M05 is the same as -M5%. To limit the detection to an exact rename, use -M100%. By default, the similarity index is 50%.

Answer 2

If the file location has somehow changed, you may need to specify git log - follow :

 $ git checkout master $ git log --follow -- file | grep A 

You can check if there is a difference between git log --oneline -- file and git log --oneline --follow -- file to see if the file has been moved.