Why would my git master branch have the current HEAD not be the most recently pushed file?

Question

Apologies if this has already been asked. I spent quite a long time looking through old SO posts on Git but have not yet found one that really matches this case.

I'm on a team of 5 developers using Git on a project. We have been using it without any real issues for about a year now. We have Gitosis set up on a shared server and do most of our work in the master branch, although we split of into side branches quite often for new features etc.

This week I've seen some weird behavior with our master branch that I don't understand- behavior that is effectively losing commits and causing developers to re-fix and the re-do changes that have already been made. The first time I saw it I chalked it up to human error, and assumed that I had just not pushed to the master branch as I thought. The second time I saw the problem we were able to gather a little more information it appears that the system is confused, or that one of our developers mistakenly to told git to do something that they didn't understand.

Here is what we see: If I look at a git log I can see ALL the commits. They are in order and commit diffs are all correct. However, if I look at the current version of the file, it doesn't contain all the changes of recent commits. IE, the log shows commits, but the file doesn't have those commits in it. When I look at the file history on the web interface (I believe we are using GitWeb), it's really clear that GitWeb knows that the most current file is NOT the same as the most recent file. That is, next to the most recent commit, it will add a link that says "diff to current". Two or three commits back there is no "diff to current" link, so it's clear that the current version of the file is a few commits behind the log/most recent commit.

1) How/What would cause this? If we did this ourselves with an erroneous command we would love to understand how to avoid it in future.

2) How can it be repaired? My guess is that if could explicitly grab the most recent commit but who's to say that in doing so we haven't lost work in other files in a similar way. The whole thing is rather unnerving as we're really not sure what has been lost at this point.

Thanks so much for any advice.

Answer 1

Just off the top of my head, does the repository you're pushing to have a workspace? That is, if you go to the directory where the repo lives, do you actually see your revisioned files? If so, that's probably a bad sign. You should only push to bare repositories. If someone did push to a non-bare repository, you can reset the workspace to the current head by doing git reset --hard in there.