Re: rsync update appears broken now

Linus Torvalds <torvalds <at> osdl.org> writes:

master.kernel.org:/pub/scm/git/git;

Yes, I screwed up.  One honest mistake and another stupid one.

Note that "those of us" above include everybody who did "git-clone" to set up the repository and left the default "Pull: master:origin" line in .git/refs/remotes/origin.

Sorry, and yes that was the "honest mistake" part. I know I should never rewind beyond what I already have pushed out, and usually I carefully follow that rule.

But this time I forgot that I pushed something out and also failed to re-check what I pushed out before rewinding (the check is done by fetching from master.kernel.org myself).

And another stupid mistake part was when I pushed out the result. send-pack correctly refused to update the master side, but I forced it without much thinking.

Sorry about these mistakes.

Having said that, all is not lost. Your message made it sound like the new head was completely re-rooted and there is no common commit (which almost gave me a heart attack), but I do not think it is that bad. It is more like pulling from two places.

               -----(A) head merlyn and everybody
             /          pulled from kernel.org previously
  --- common ------------------------------------(B) head rebased and pushed
                                                     out by mistake

The "parent" head you described in your message is A above, and what is on kernel.org is B. A is known as "origin" in the default setup git-clone makes.

If you have *no* further development on top of (A), the recovery is simple.

   $ git checkout master ;# make sure you are on your "master" branch.
   $ git fetch origin +master:origin ;# force "origin" to be (B)
   $ git reset --hard origin ;# reset your "master" branch to (B)

If you had any further development on top of (A), then the graph would look
like:
               -----(A)---------------(X) your tip
             /
  --- common ----------------------(B)

The merge conflict message you got when you pulled is result of trying to merge (X) and (B).

There are two things we could do.

One is to forward port your changes between (A) and (X) on top of (B):

   $ git checkout master ;# make sure you are on your "master" branch.
   $ git tag anchor-a origin ;# stash (A) away
   $ git fetch origin +master:origin ;# force "origin" to be (B)
   $ git checkout -b rescue-stupid-junio origin
   $ rm -fr .dotest
   $ git format-patch -k --stdout anchor-a..master | git am -k -3

Depending on the changes between A and X, forward porting may result in conflicting/unapplicable patches. The individual changes are found in .dotest/ directory and you can re-run 'git am -i' after fixing up the conflicts.

Then validate the tip of the result to make sure forward porting did not lose your changes:

   $ git diff origin..rescue-stupid-junio

If the result look OK, then we can make this your master branch.

   $ git checkout master
   $ git reset --hard rescue-stupid-junio

and clean things up by

   $ rm -f .git/refs/tags/anchor-a
   $ git branch -d rescue-stupid-junio

Another thing we could do is to treat as if this stupid maintainer briefly had a twin who did concurrent development, and merge (X) and (B).

   $ git checkout master
   $ git pull origin +master:origin

This, as Merlyn and you saw, probably would result in merge conflicts which need to be resolved manually.

Unfortunately I do not have access right now to commits between "common" and (A) in the above picture (I am at work), so I cannot try any of the above out myself.