views:

67

answers:

2

The file that's mystifying me is v5/employer/controllers/_employer.php.
In the first image, you'll see that Brian changed the file in a commit on 14:55:47 called "time to commit stuff".

alt text

But that commit's only child (second image), a merge operation Brian did at 14:56:45, does not show any changes to that file. But it's different!

alt text

When you look at the actual contents of that file after the merge operation, you can see it's different than the version before it, but nothing shows up in the patch view.

So basically, Brian's changes in that "time to commit stuff" commit got lost, at least for that file.

Now if I run gitk --all v5/employer/controllers/_employer.php, I get the third image--which doesn't show the commit at all!

alt text

What's going on here? Are we all crazy, or is git really losing our data?

A: 

What does git reflog tell you?

Tronic
I've never used git reflog, and the man page doesn't make it obvious how it would be helpful in my situation. Could you give me a little more guidance?
Ben Dilts
Also, if it's helpful, other changes made in that same commit _have_ made it all the way down to the current HEAD. Just not ones in that file.
Ben Dilts
It just tells you the most recently done operations on the entire repository. Might give you a hint of why the repository is messed up and it also could give the commit IDs that you can use to recover the lost commits (either by git merge or by git reset).
Tronic
A: 

Yep, it's starting to look like it was a conflicted merge gone bad. The merge commit that's a child of "time to commit stuff" has another parent (obviously; it's a merge), and the note states there was a conflict in _employer.php.

We went back and walked through what happened in that merge. It turns out we used git gui's "Use remote version" to try and resolve the conflict rather than an external merge tool like meld, since the conflict was really trivial. As it turns out, that button doesn't just resolve conflicts with the remote version, it bulldozes the entire file with either the local or remote version it's merging from.

And since the file is identical to one of its parent commits, it doesn't show up as a modified file in that revision. That was confusing to me at first, since the file was changed after merging in another branch. But the reality is, I wasn't merging in a branch, I was merging two branches, and it might as well have been a merge in the other direction where the file genuinely didn't change.

Ugh. Well, it was user error (surprise, surprise). Let this be a warning to always use an external merge tool to resolve conflicts.

Ben Dilts