Reputation: 126847
I just did something dumb. In my fooclient project, I just did:
git remote add official https://github.com/fooserver
git pull official master
In other words, I pulled a completely different codebase (the server, instead of the client) into my working directory. Not surprisingly, there weren't many merge conflicts (the file names are all completely different, after all). Also not surprisingly, Git completely failed to warn me that the repos didn't have a single common ancestor.
In this particular situation, I'm able to recover by doing this:
cp file-i-worked-on.js ~
git reset --hard HEAD # to discard broken merge conflicts
git checkout a12345 # where a12345 is the latest head of fooclient that I had checked out
cp ~/file-i-worked-on.js .
But what would be the more general strategy?
Upvotes: 3
Views: 166
Reputation: 129782
From now on
git fetch
Inspect what you got in gitk or git log or anything else. Now merge or rebase what you got to where you want it to go.
Upvotes: 0
Reputation: 97014
This will reset you to the last state master was in:
git reset --hard HEAD@{1}
This is possible because of the reflog. Running git reflog
will show you the reflog, and allow you to verify you're resetting to the correct state.
Upvotes: 4
Reputation: 311755
After removing the unwanted remote (git remote rm ...
), just git reset --hard
to the spot you want your current branch to be on.
git reset --hard origin/master
If you were on master
before, this resets your master
to be the same spot that your origin remote's master is it. That's it!
Upvotes: 0