Why do the changes introduced by a commit not show up in my working tree?

Question

I'm having an issue where git says a commit is merged, but the changes from the commit aren't in my working tree. To make things even weirder, git log --name-status 362dde7 tells me that the commit modified a file, but git log -- path/to/modified/file.java does not show the commit. For example:

Ensure that the commit in question exists on both the dev branch and feature branch.

$ git branch --contains 362dde74f142831c99820b999558a2e8f49f66e8
* dev
  feature

List the files modified by the commit.

$ git show --name-status 362dde74f142831c99820b999558a2e8f49f66e8
# commit summary... #
M       path/to/modified/file.java

Now when I do the reverse (list the commits that have modified the file) the commit isn't listed.

$ git log path/to/modified/file.java
# Commit 362dde7 isn't listed here

If I switch to the feature branch and follow the same steps, everything works as expected.

$ git checkout feature
$ git show --name-status 362dde74f142831c99820b999558a2e8f49f66e8
# commit summary... #
M       path/to/modified/file.java
$ git log path/to/modified/file.java
362dde7 Commit summary

Basically, the same commit exists on both dev and feature, but the working tree changes only show up when I have feature checked out. Does anyone have an idea as to why this is happening?

Answer 1

Try it again with --full-history. When git log is hunting for commits that modified a path, by default it does history simplification, which is to say it doesn't show any commits from which all changes are easily seen to have been either dropped or already merged (and those latter therefore appear in some other commit git's going to list anyway).

Consider this graph, with commits identified by the content of "path":

 o---o---A---A---B  master HEAD
  \         /
   o---X---Y        topic

The idea is, git presumes something in your current checkout prompted you to hunt down the source of changes in the checked out file — and if, at a merge point, no change from one parent appears in the merge result, nothing in that parent's history affected your copy of the file.

Think cherry-picks and squash merges and rejected changes and widely-disseminated hotfixes and multiple pull sources.

Answer 2

$ git init so19234836
Initialized empty Git repository in /tmp/g/so19234836/.git/
$ cd so19234836/
$ echo "content created" > file
$ git add file
$ git commit -m c1
[master (root-commit) a965818] c1
 1 file changed, 1 insertion(+)
 create mode 100644 file
$ git checkout -b feature
Switched to a new branch 'feature'
$ echo "feature change"> file
$ git commit -am f1
[feature eaf4121] f1
 1 file changed, 1 insertion(+), 1 deletion(-)
$ git checkout master 
Switched to branch 'master'
$ git merge -s ours feature
Merge made by the 'ours' strategy.

Now I have similar state of the repo:

$ git log file
commit a965818706c47d065b81a994aeb5fc24cd77d001
Author: Anatoly Kupriyanov <[email protected]>
Date:   Mon Oct 7 22:44:52 2013 +0100

    c1
$ git checkout feature 
Switched to branch 'feature'
$ git log file
commit eaf41212872d784d4e4e50e62167072d35b6167f
Author: Anatoly Kupriyanov <[email protected]>
Date:   Mon Oct 7 22:49:02 2013 +0100

    f1

commit a965818706c47d065b81a994aeb5fc24cd77d001
Author: Anatoly Kupriyanov <[email protected]>
Date:   Mon Oct 7 22:44:52 2013 +0100

    c1

$ git branch --contains eaf41212872d784d4e4e50e62167072d35b6167f
* feature
  master

So, basically if you do a merge from another branch but revert any changes in the merge commit for the file, content is not changed, but merged commits appear in the history.