Git Push to old repo

Question

I have a github repo that has not been pushed to in a couple months (I know, bad idea) during which time a fair amount of development has been done. I went to push to the repo and I received this error:

error: failed to push some refs to 

https://github.com/SteelcaseEbiz/PDE_UI_engine.git'
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.

This is not a duplicate. I asked a very specific question, see below, which no one has answered.

If I were to pull like it's suggesting, would I be pulling the old version down thus overwriting all of the changes I've made?

Your commits are out of sync with the remote. You probably just need to merge the upstream commits first. — Todd, Jun 18 '18 at 18:39
[Better related question](https://stackoverflow.com/questions/24114676/git-error-failed-to-push-some-refs-to#24114760) but too late to revise first comment. — Todd, Jun 18 '18 at 18:49
Possible duplicate of [Github "Updates were rejected because the remote contains work that you do not have"](https://stackoverflow.com/questions/18328800/github-updates-were-rejected-because-the-remote-contains-work-that-you-do-not-h) — phd, Jun 18 '18 at 19:26
@phd Read my post more closely. I asked a very specific question that was not answered in any of the other posts. — Evan Lalo, Jun 19 '18 at 13:31
You would be merging whatever changes has been done in that remote since the last common commit with your local commits. For the future it's better to *lead* with the most important question, and not bury it below an error message at the bottom of the question, this makes it easier for people to pick up what you're really asking. — Lasse V. Karlsen, Jun 19 '18 at 13:48
In short, it is impossible for us to answer what specifically you would be merging in. Depending on the changes, you could add a lot of code into your local branch, you could remove a lot of code, you could change a lot of code, etc. You would not simply *lose* it, but if the changes done in that remote explicitly removes or changes your code, then yes, merging with that remote might remove code in your local repository. — Lasse V. Karlsen, Jun 19 '18 at 13:57
It's either `git pull` or `git push --force`. Nothing specific, clearly a dup. — phd, Jun 19 '18 at 16:09
@phd If you ignore the question, which was not answered in other posts, then sure. — Evan Lalo, Jun 19 '18 at 16:22
@LasseVågsætherKarlsen, your comment cleared things up for me. If you submit as an answer I'll accept. Thanks — Evan Lalo, Jun 19 '18 at 16:23

score 1 · Accepted Answer · answered Jun 19 '18 at 18:52

The message given by Git is the important one but it's more important to understand what it is saying beyond just the text on the screen.

Basically, this is the situation: In that remote repository, there are commits on the branch you tried to push to that you don't have locally.

Whether you originally avoided fetching them or they have been added into that repository after you last fetched from it is unimportant, the important bit is that they're there, and you don't have them.

So to answer your question, we cannot really answer your question of what is going to happen if you pull/merge those commits into your local repository.

The following scenarios are all possible, and there probably more scenarios conceivable as well:

Those commits are completely unrelated to whatever it is that you're afraid of losing. Merging them in will add those changes to your local repository by adding new files, modifying existing ones or even removing some files.
Those commits touch the very files you're afraid of losing, by modifying them. Whether the merge will succeed or not depends on what kind of changes in what areas of those files. It can turn into a merge conflict you have to resolve or the merge can go through just fine automatically.
Those commits delete the files you're afraid of losing. If you've also modified the same files locally then you will have a merge conflict where you have to choose whether to keep the modified files or to delete them. If you haven't changed them locally then they will be deleted.
Any mix of the above operations.

In short, it is impossible for us to tell you what the outcome will be.

But fear not, one of the big things I'm a fan of with Git is that you can experiment.

So do the following:

Make a local clone or copy of your entire local repository
In the copy/clone, add the remote you want to merge from as a remote
Pull/merge in the changes from this remote, resolve any conflicts

Worse case scenario: You destroy that copy/clone. If you think you simply messed up, destroy the clone and try again. If you think the two repositories cannot be reconciled with a merge, you now have your answer as to what will happen.

Note that you do not really have to operate on a clone, you can clean up a botched merge in your real local repository, but I advise this anyway so that you're surer that you won't accidentally destroy anything important.

Git Push to old repo

1 Answers1