Question

I have a bare git repository that I use to push to and pull from on a linux machine (let’s call the bare git repository remote originlinux). From my working repository that has originlinux as a remote I push and pull until finally I decide to put it on github. I add the repository for github on their web gui and add the remote repository on my working repository (let’s call the remote origingithub) using the git remote add command followed by git pull --rebase, then git push (pull before push since I wasn’t allowed to simply push to a newly created github repository without getting one of these: ‘hint: Updates were rejected because the tip of your current branch is behind’. I figure this has something to do with their option to create a readme file). And here’s the issue, after performing these steps, the originlinux repository is completely not synced with the origingithub repository even though they have exactly the same commits and were pushed to from the same exact working repository. Could someone please explain in good detail why this occurring and also what I could do differently to prevent this from happening without reordering how I create my remote repositories? It seems like the workflow or order of operations I’m using doesn’t make sense in git land, but how else would you keep multiple remote repositories sync’d on one working copy?

Thanks!

Answer 1

The two repositories do not have the same commits.

When you did git pull --rebase, you rewrote the entire history of the project so that every revision contains that readme file. So every commit in the history will have a different SHA1 identifier.

There are a couple of ways that you may be able to recover from this.

First, you could revert the state of your local repository to match the state or your first (non-github) remote. This would eliminate the readme file that you created on github (you can copy that to some other location and add it back in to git later if desired), along with any changes that you hadn’t pushed to the first remote (including changes that haven’t been committed).

git reset --hard originlinux/master
git push -f origingithub

The -f option there causes the push to be forced even though that is removing some commits. This is something that should be avoided in general, but it is sometimes necessary such as in this case.

The other option would be to just do a force push to your first remote, accepting the new history caused by the rebase.

git push -f originlinux

If the three repositories that you mentioned are the only ones, it shouldn’t matter much which of these methods you use. If there are other repositories you may want try to determine which version of the history is more widely known, and keep that version.