Hi,

On Mon, 12 Nov 2007, Nicolas Pitre wrote:

quoted text
> 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?
-
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