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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html