Weird behavior of git

Question

The other day, I upgraded tiny_mce in a project that's version-controlled with git. At that time, I made a git branch for the change and merged it to master and deleted the branch. Everything worked fine.

Also, I changed the remote repo to another server and changed my .git/config. But I found out that I made a mistake like the following.

[remote "new_repo"]
  url = ssh://[email protected]/~/path/to/myproject.git
  fetch = +refs/heads/*:refs/remotes/new_repo/*
[branch "master"]
  remote = old_repo <= WRONG
  merge = refs/heads/master  

It should be remote = new_repo. I corrected it later and it seemed to work fine.

But after that, if I do "git status", the old tiny_mce files overrode the new one and they are in the changed list but not committed. So I have to "git reset --hard HEAD". That happens on other copy of my project (updated via git), too. But I can't reproduce it. It seems to happen randomly.(or I just can't find the pattern yet.)

What's going on and how can I fix it?

Here's my "git branch -a":

choir
* master
remotes/old_repo/master
remotes/new_repo/master

Updates and fixes:

It turned out that tiny_mce gem that my rails application uses copies the old tiny_mce and overwrites the new one every time I run "rake some_task". I upgraded the tiny_mce gem.

Answer 1

1. The remotes/old_repo/master is a result of your manual rename. In future, prefer git remote rename, or even just git remote set-url to update your remotes, and it'll clean up all these kind of things for you.

   Cleaning up after the fact is a pain; git remote prune is supposed to deal with these problems, but refuses to do so if the remote has gone missing. git branch -dr old_repo/master?

2. git reset --hard HEAD will do very little if your HEAD is wrong.

   Inspect it with git symbolic-ref HEAD, or just cat .git/HEAD, or, even better, run git branch -avv. These will tell you where your HEAD is pointing.

   It's probably pointing at old_repo/master instead of new_repo/master? If so, you can (assuming you're aware of what reset --hard does to your uncommitted changes), git reset --hard new_repo/master, and never speak of this again.