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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 12, 2007, 22:17 UTC
Message-ID: <Pine.LNX.4.64.0711122212540.4362@racer.site>
In-Reply-To: <alpine.LFD.0.9999.0711121702030.21255@xanadu.home>

Hi,

On Mon, 12 Nov 2007, Nicolas Pitre wrote:

Show 14 quoted lines

> On Mon, 12 Nov 2007, Junio C Hamano wrote:
> 
> > 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.
> 
> While that could well be true, I don't see this condition happening 
> solely in the context (hence because) of an empty clone.

Hehe.  That is a very delicate play with predicates.

If Alice and Bob clone from an empty repository, and both work on it, there is _no way_ that they can have a common ancestor[*]. Hence, an empty clone _would_ be a cause of that condition.

The only way to _not_ have this condition would be at least one side starting with a non-empty clone. Or with an _effectively_ non-empty clone.

Ciao, Dscho

[*] Oh yes, theoretically they could commit the same commit with the same author info and author timestamp, but to be a common ancestor, they would also have to use the same _committer_information, which means that Alice == Bob, as far as Git is concerned. Do I have to go on?