9

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 afc2dec4a828de05350c39526eeecf9d3a15e465
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?

Michael Lorton
  • 43,060
  • 26
  • 103
  • 144
  • this is strange, did david do a `push --force` ? – Marian Theisen Sep 24 '11 at 19:45
  • What does the diff say for the most recent change to the file? Was it actually changed? – Andy Sep 24 '11 at 19:58
  • Try `git log --decorate=full` just in case there is a tag or branch named `backend/theimportantfile.js`. Wouldn't that be funny? – rodrigo Sep 24 '11 at 20:26
  • @rodrigo -- that would not be funny, but in fact, the actual name was much longer and there were several files in the same situation. – Michael Lorton Sep 24 '11 at 22:36
  • The log said the change had been made in afc2dec and then reverted in 194b7f (which made some sense). – Michael Lorton Sep 25 '11 at 00:39
  • Does `git log --cc` help any? Or even `git diff-tree -c|--cc `? Or perhaps `git blame `? You want to try to find where the good changes were introduced on your end, and where the other end reverted them (or if history has been rewritten so they were never there). You can also try `git log -G|-S` (see the manpage). – Cascabel Oct 05 '11 at 23:46

3 Answers3

2

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.

2

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.

Frosty
  • 6,213
  • 3
  • 24
  • 20
  • David is using a very simple-minded Windows GUI on top of Git. He *certainly* didn't specify some weird strategy. – Michael Lorton Oct 04 '11 at 19:15
  • Simply overwriting a file with a copy somewhere would do it? Using 'git checkout ' could also be the culprit. Or having the file open in an editor and re-saving it then committing the results... – Frosty Oct 12 '11 at 18:11
1

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

Community
  • 1
  • 1
shadowland
  • 757
  • 1
  • 6
  • 20