Junio C Hamano wrote:
quoted text
> 
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html