How does a commit disappear from the log of one file?

So I made a change to a file, pushed it to our main repo, saw it there. David pulled from that repo and did -- well, something -- and couldn't see my change. Since David is a typical Microsoft victim, I asked him to push what he had back to the repo and I'd look at it there.

git log --name-only produces

commit 194b7f5dbb59d29ace340a376f10906752978db5
Merge: 484df79 afc2dec
Author: David Good <david@company.com>
Date:   Sat Sep 24 11:47:14 2011 -0700

[ David's merge ]

commit afc2dec4a828de05350c39526ee开发者_如何学编程ecf9d3a15e465
Author: Michael <info@company.com>
Date:   Sat Sep 24 10:58:54 2011 -0700

[ my changes ]

backend/theimportantfile.js

commit e4e2f9ce9df3adf5ed0547ed16521eb742cc2ac1
Author: Michael <info@company.com>
Date:   Sat Sep 24 10:47:09 2011 -0700

[ some other thing ]

but git log backend/theimportantfile.js produces

commit eb470fe1792220779b14e90337f74fb216fc9f7f
Author: David Good <david@company.com>
Date:   Mon Sep 12 17:20:25 2011 -0700

[ comment ]

commit 63ddd2be020092a4bf65d1eac106ece5fd7fbbd3
Author: David Good <david@company.com>
Date:   Fri Sep 9 16:23:53 2011 -0700

[ comment ]

So according to git, backend/theimportantfile.js hasn't been touched in weeks but it was also changed two hours ago with the afc2dec commit. How can I track down what happened?

It appears David's merge is what did you in. I say this because that the merge appears to have 'reverted' your changes.

#this command will show you if anything 'strange' happened during the merge"

git show 194b7f

If that command gives no interesting output then David perhaps merged with an 'ours' strategy or did the clever 'cp my files to a temp location; git merge; overwrite conflicting files; git commit' workflow.

Regardless of how this state was arrived at the merge needs to be discarded and redone as it is obviously faulty. You may also consider changing your workflow such that David doesn't need to do merging anymore but rather submites informal (or formal) "pull requests" and you take care of the merging.

I'm not sure if this is the nature of your problem, but by default, git log will sometimes filter out commits that it thinks aren't "useful" or "interesting" in order to understand the final state of a commit tree. From the git log docs:

Sometimes you are only interested in parts of the history, for example the commits modifying a particular <path>. But there are two parts of History Simplification, one part is selecting the commits and the other is how to do it, as there are various strategies to simplify the history.

The following options affect the way the simplification is performed:

Default mode
Simplifies the history to the simplest history explaining the final state of the tree. Simplest because it prunes some side branches if the end result is the same (i.e. merging branches with the same content).

Instead of using the default mode, you can pass in the --full-history flag on your file and see if the "missing" commit shows up that way:

git log --full-history -- backend/theimportantfile.js

From the git log docs:

--full-history
Same as the default mode, but does not prune some history.

Edit

I know this works sometimes because I experienced a situation where I had a commit X in master that contained a change to a file theFile. Commit X was then cherry-picked into anotherBranch by a coworker, so let's call the new commit Y. Then anotherBranch was merged into master.

When we did

git log -- theFile

we would not see Y in the list of commits, just X, but when we used

git log --full-history -- theFile

only then would both X and Y show up. I guess Git didn't show Y by default because it introduced an identical change to the final state of the commit tree, since it was cherry-picked from X.

It looks like he may have had a merge conflict and resolved it by accepting his version (which was probably a non-existant file) instead of yours. You can bring the file back. See how to resurrect a file or folder