Search code examples
gitgit-push

Git Push to old repo

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?

Solution

  • 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:

    1. 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.
    2. 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.
    3. 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.
    4. 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:

    1. Make a local clone or copy of your entire local repository
    2. In the copy/clone, add the remote you want to merge from as a remote
    3. 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.