Re: Cloning empty repositories, was Re: What is the idea for bare repositories?

From: Andreas Ericsson <ae@op5.se>
Date: Nov 13, 2007, 00:13 UTC
Message-ID: <4738EC25.20108@op5.se>
In-Reply-To: <7v4pfr2kmh.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:

Show 10 quoted lines

> 
> His second point is also a real issue.  If you allowed cloning
> an empty repo (either bare or non-bare), then you and Bill can
> both clone from it, come up with an initial commit each.  Bill
> pushes his initial commit first.  Your later attempt to push
> will hopefully fail with "non fast forward", if you know better
> than forcing such a push, but then what?  You need to fetch, and
> merge (or rebase) your change on top of Bill's initial commit,
> and at that point the history you are trying to merge does not
> have any common ancestor with his history.

If we assume zero communication between these two, the alternative is this: Bill starts hacking in his own repo and then uploads his .git dir to the server. David starts hacking in his own repo and then uploads his .git dir to the server.

The only difference between the two scenarios is (assuming they have write access to those shared directories) that the last-in wins in the second case, while first-in wins in the first one.

Oh, and the fact that the first to upload his .git dir to the server will lose all his refs if he isn't careful to save his original copy until they both have established which "first" commit to use, which could take a while in this imaginary world where they don't seem to be speaking to each other but are still working together.

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