On Fri, Aug 3, 2012 at 4:00 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Eugene Sajine <euguess@xxxxxxxxx> writes: > >> I think the best variant would be to do something like: >> >> $ git pull --rebase /refs/heads/*:/refs/heads/* >> $ git push origin /refs/heads/*:/refs/heads/* > > You perhaps meant "worst" not "best" here. From the point of view > of people who have pushed into the "origin" repository we see above, > their history is rewritten; you are screwing half the population by > doing this. > > Not allowing B to accept pushes while it is not positively sure that > A has gone down would of course be the best solution (in your scenario, > B started serving when it merely found out that *it* cannot contact > A), but barring that, the recovery for two histories at A and B, > once they diverged, should be to "merge" corresponding branches. Junio, Thanks for chipping in! Please correct me if I'm wrong, but wouldn't merge result in the same history changes for people pushing to the origin (bareA)? Still all their consequent changes will not be fast-forwardable because of merge commit. Or am i missing something? It might be that the command i specified is incorrect. I meant that I would execute "pull --rebase" (or proper analogue for bare repo) for each branch on B side and then push those refs to A. This way it would pretend that B is another "dev repo". May be you can advise on correct commands to do that properly? I'll think about not allowing pushes to B while not sure it is really time, so it is not reacting on irrelevant connectivity issues or bareA downtime due to the maintenance. Thanks, Eugene -- To unsubscribe from this list: 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