This summer I am proctoring CS 373 under Glen Downing. Its has thus far been an enjoyable experience. The main thing I do, besides answer student questions, is grade the quizzes.
One coincidence that I ran into today at work was a bad merge. One of the quizzes last week in that class had asked what the two most common errors that occur with version control are. One that every one missed was lost changes from a bad merge. And that exact thing happen to me today.
Here at work we use perforce which is actually a pretty decent version control system. I have so far enjoyed using it and its interface is really great. One of the was you can stage all your changes to be submitted (perforce's term for a commit and push) is by "Reconciling offline work". That basically means that it goes through all the files and sees if any have been changed or new files that have been created. This is very convenient except that it breaks one of the great things about perforce. Whenever you want to edit a change you "check it out" which basically just lets others know that you are working on the file. That way, when they go to edit it you are aware changes are being made or have been made.
Since my colleague had done the reconcile he had to the merge and had altered the code not knowing a previous change was made. This led to his bad merge and the changes I had made were lost.
When everyone got his revision (perforce's term for what is known as a pull in git) to get his edit, the lost changes broke our game. This led to lost time because the error had to be sorted out. It was tedious.
Moral of the story, be careful when you merge and understand the context of the other code you are merging with yours. If you need to get the authors of the outside code to help you do the merge if you don't know what is necessary and what ins't.