Re: need help with syncing two bare repos

[Junio C Hamano <gitster@pobox.com>]

Eugene Sajine <euguess@gmail.com> writes:

> On Fri, Aug 3, 2012 at 4:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Eugene Sajine <euguess@gmail.com> 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.