Eugene Sajine <euguess@xxxxxxxxx> writes: > 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. > > ... 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? Welcome to the world of distributed version control. Even with a single server, it always is possible that other people have been working on their changes and pushed their results out while you are working on your changes when you are working with others. It is perfectly expected that your changes may not be fast-forwardable. In such a case, you can, and you are expected to, fetch the updated tip from the public meeting point, integrate your work with it and then push the result back. That is not an issue. If the project has "strictly linear history only" policy [*1*], then the "fetch the updated tip, integrate your work and push back" would involve a rebase on the participant's part, and only in that very narrow context, it wouldn't make a difference if you rebase at the server end while doing your recovery procedure. In a way, the rebase during your recovery procedure is doing the rebase the particupants would have to perform anyway for them. But in a more general workflow where project participants are either allowed or encouraged to merge (as opposed to rebase and immediately push the untested results out), the history resulting from a merge by a participant, when he finds that what he has is not a strict descendant of the recovered A's history, will contain the commits he made originally to A when it was half-alive and their doppelgänger commits your recovery procedure produced by rebasing, which is a disaster. [Footnote] *1* Projects can enforce strictly linear history by rejecting push of a history with any merges in their pre-receive hooks. Such a practice may be denying its participants major benefit of Git, namely, distributedness, but it is probably easier to explain to people coming from CVS or systems where branching and merging are impossibly hard. -- 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