The file that's mystifying me is v5/employer/controllers/_employer.php
.
alt text http://img96.imageshack.us/img96/850/figure1.png
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 http://img190.imageshack.us/img190/7787/figure2u.png
When you look at the actual contents of that file after the merge operation, you can see it's different than 开发者_如何学Cthe 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 http://img704.imageshack.us/img704/7135/figure3.png
What's going on here? Are we all crazy, or is git really losing our data?
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.
精彩评论