Short version of my question : For years, I have been using a simple, single one-branch, one-contributor public online Github repo. A few days ago my computer died suddenly and I bought a new one. Now Github refuses to connect the local repo
from my new computer to the online repo saying "refusing to merge unrelated histories". What do I do ?
Long version of my question : here is the exact sequence of commands that I did in my new computer :
Step 1 : Download git, use `git config` to tell git about my username & email. Worked fine.
All the following command were executed in my new local repo's main directory
Step 2 : `git init`. Worked fine.
Step 3 : Do a `git add` on all my files. Worked fine.
Step 4 : Do the first commit : `git commit -m "First commit from new computer"`. Worked fine.
Step 5 : Do `git remote add origin https://github.com/roparzhhemon/myremoterepo.git`. Worked fine, according to
`git remote -v`.
Step 6 : `git push`. Got the following error message :
fatal: The current branch master has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin master
Step 7 : Do as I'm told, and type : `git push --set-upstream origin master`. Got the following error message :
error: failed to push some refs to [remote repo] hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Step 8 : Do as I'm told, and type : `git pull`. Got the following message :
warning: no common commits remote: Counting objects: 11450, done. remote: Compressing objects: 100% (17/17), done. remote: Total 11450 (delta 13), reused 17 (delta 8), pack-reused 11425 Receiving objects: 100% (11450/11450), 1.96 MiB | 2.65 MiB/s, done. Resolving deltas: 100% (7710/7710), done. From [remote repo] * [new branch] master -> origin/master There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull <remote> <branch> If you wish to set tracking information for this branch you can do so with: git branch --set-upstream-to=origin/<branch> master
Step 9 : Do as I'm told, and type : `git branch --set-upstream-to=origin/master master`. Seemed to work, output the following :
Branch 'master' set up to track remote branch 'master' from 'origin'.
Step 10 : Try `git pull` again. Got the error message :
fatal: refusing to merge unrelated histories
Step 11 : Try `git push` again. Got the error message :
To [remote repo] ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to [remote repo] hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Solved! Solved! Go to Solution.
If you just start a new repository, the history will be completely different than GitHub knows it.
git clone <repo>
and just make commits on top of that. Then push.
This comment should be deleted or at least not appear as first, See the accepted answer.
To those saying this answer is wrong: It isn't. The poster absolutely got themselves into trouble in the first place with:
$ git init $ git add <files> $ git commit -m "First commit from new computer" $ git remote add origin https://github.com/roparzhhemon/myremoterepo.git
All of that should have been:
$ git clone https://github.com/roparzhhemon/myremoterepo.git
which would have automatically copied the contents of the remote repo and added it as the remote origin. You're not meant to be doing that by hand.
If there are local files to add that aren't in the remote repo, those can be added after the clone operation. Then the history won't be divergent, the new commit will have the HEAD of the remote repo as its parent, and git push will go right through.
The key is right in the name of the remote: "origin". It's meant to be the source of your local repo's copy of the history, not the destination for it.
The accepted answer may be the solution to this problem, when it's already happened, but it's much better to never get into that situation in the first place.
I got into this problem following a guide book that started with a local git repo and then tried to show how to go remote with a github account. Left out was all the .ssh key stuff and this. Thanks. This answer worked for me, is much cleaner and doesn't seem to be leaving me open to the problem versioning is supposed to prevent against.
Easy and fast solution to the problem I also got into after changing computer!
First I tried to solve it the way described by the author of the topic but I ended up with info from git that my local repo is ahead of two commits to remote one. Thats not what it should be when coping repo to your computer, is it? :)