Hi, On Mon, 12 Nov 2007, Nicolas Pitre wrote: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
