On Fri, 28 Dec 2012 08:09:38 -0800 (PST)
Trans <transf...@gmail.com> wrote:
> Hi, I just screwed my repo and need advice on how to get it back.
Nothing is really screwed, see below.
> I have been doing some major work on a project, and was finally ready
> to push it. Foolish me did the work in master. So I go to push and I
> am told, "To prevent you from loosing history non-fast-forward
> updates were rejected...". Yatta yatta. I don't see why I got this
> message at all.
By default, Git does only allow updating a remote branch if the line of
history with which you're trying to update that branch *contains* that
branch in it. That is, you have just added a bunch of new commits onto
that line of history and now tries to push it.
In your case, you somehow managed to update the remote "master" with
the commits that are not on your local "master".
Basically, that might have happened due to these two reasons:
1) You updated your remote "master" from some other repository
(say, from another workstation) and did not update your local
"master" in your current repository with those commits.
You have then recorded a number of local commits thus creating
"a fork".
2) You force-pushed some other branch into remote "master".
> I am the only person who has worked on the project
> and this is the only repo that has ever pushed upstream. So I figure
> whatever it is, it much be some miniscule change, nothing to fuss
> over. And as the instructions say, "Merge the remote changes (e.g.
> 'git pull'), before pushing again",
Yes, typically this is what you're supposed to do. If you look at the
reason (1) above, this is what usually happens if several developers
work on a branch in parallel and do intertwined pushes: if someone
managed to push their work before you, you're supposed to reconcile
these new changes with yours (unpushed) changes and then re-try your
push.
> I did so.
> I got six huge CONFLICTS and 5 files were DELETED! :-( I can fix the
> conflicts, but how do I get the deleted files back? I tried to
> checkout the last commit reference but it won't let me do so until
> all the conflicts are resolved.
>
> At this point I am scared to breath hard on my keyboard. I don't want
> to do anything until I get some expert guidance for risk of loosing
> the files for good.
First, you have to understand the situation.
You currently have two branch tips of interest:
1) Your remote "master" you tried to pull (pull == fetch then merge).
2) Your local "master" into which you tried to pull.
Note that both these two commits are unaffected by the merge and its
possible outcome -- a merge is either cancelled (by resetting the
work tree and index state, see below) or results in a *new* commit
being recorded; in either case the wannabee parents of the prospective
new merge commit are not touched.
Hence I'd propose to do this.
1) Stay cool as there's nothing to worry about. ;-)
2) Undo the unhappy merge.
To do this, run `git reset --hard`.
This will bring the work tree and the index into the state of
the tip of your currently checked out branch ("master")
as if the merge attempt did not happen.
3) Do `git fetch origin` (if your remote is known by a different name,
use it instead of "origin") to bring the master from your origin
repo into your local branch available as "origin/master".
By now, you have the merge (pull) undone and both tips available at
your disposal: local "master" is checked out, the remote's idea
about "master" available as "origin/master" (or whatever).
Inspect the history of that remote "master" by running
`git log origin/master` or whatever GUI tool you prefer.
At this point you have to decide why the branches have diverged
and what to do about this. Tools like `gitk --all` or
`git log --all --oneline --graph --decorate` might visualise the
history for you so it might be simpler to look at.
--
