Re: git-reset and clones

Paul Jakma wrote:

Hi,

Next dumb question:

If a git repository has a reset HEAD~X done, then any later pulls in 
clone repositories get /really/ upset, with:

$ git pull
* refs/heads/origin: does not fast forward to branch 'master' of 
/home/paul/foo-git/;

Type of thing. This seems to be a similar issue to:

    http://www.gelato.unsw.edu.au/archives/git/0510/10767.html

The question is has this improved at all since last year? Is there 
anything the origin repository maintainer (the one who did reset) can do 
to recover from this?

I'm guessing the answer is:

Yes:

1. where git-reset has already been done, manually update the
  refs back to the previous HEAD
2. then use git-revert, and continue to use git-revert only.

My question then would be, presuming some innocent repository maintainer 
has already done 1, what's the easiest way to accomplish 1?

(they shouldn't have done it obviously, but assume they're git newbies, 
made an honest mistake and now need to recover, preferably without 
having to involve those who pull).

I *think* this should work. Get a backup before trying. Note that I'm 
assuming "git reset" hasn't been run several times, or you'll have to 
replace ORIGIN with whatever HEAD pointed to before the first reset.

In mothership-repo:
	git checkout master
	git branch next-master ORIGIN
	git rebase next-master; # fix conflicts and commit
	git branch -d master
	git checkout -b master next-master
	git -d next-master
	git revert (the bad commits)

Some shortcuts can be taken if we're not to use git commands the entire 
way, but this is easier to explain to those newbie-ish people you mentioned.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231