rjzii
rjzii

Reputation: 14533

"git merge" resets recently edited file to older version

I'm working inside of a private repository with the remote on GitHub. After synchronizing my local repository this morning I discovered that a lot of my work had been lost and reset to a previous version. As of right now, it appears that the commit history reflects the correct work, but when you view the files, they are out of date by days to weeks. Operating under the assumption that this is a local problem I've already try various things up to and including git reset --hard [hash] and things are still out of sync.

Using the GitHub file browser it appears that some of the directories and files have the wrong latest version hash associated with them compared to what the commit history actually shows. This has resulted in things being out of date by days to weeks from when the last commit was actually made.

At this point we have been able to replicate the cause of the problem, but it is fairly bizarre since a merge is apparently causing git to revert to old files:

  1. git reset --hard [hash] - Viewing the files reflects the correct work
  2. A file has a trivial change made
  3. git add [file]
  4. git commit -m [notes]
  5. git pull - A merge is preformed with files that were committed after which the files are reverted to a much older version of the working file that was committed.

As such, what can cause this problem and how to fix it?

Upvotes: 0

Views: 640

Answers (1)

knittl
knittl

Reputation: 265141

This sounds like the history on the server was rewritten (usually the result of a push -f) and your local clone still has the old history. To Git, this is nothing else than a diverged branch between you and the remote (both have "new" commits the other does not know about). To reconcile this history, Git needs to perform a merge. This can lead to unexpected results when Git tries to merge file contents and thus changes can be missing in newly created merge commit.

If you are sure that the version on the remote is the correct one, you can perform the following steps to bring your local clone to the same state:

  1. git fetch get all remote commits
  2. git reset --hard origin/master CAREFUL, REMOVES UNCOMMITTED CHANGES

This has to be done for each clone which contains the old/rewritten history. An easier way is to just get a fresh clone of the remote repository.

Upvotes: 1

Related Questions