Junio C Hamano <gitster@xxxxxxxxx> writes: > Matthieu Moy <Matthieu.Moy@xxxxxxx> writes: > >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> >>>> > On Mon, 12 Nov 2007, Matthieu Moy wrote: >>>> > >>>> >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >>>> >> >>>> >> > So you need to populate the repository before starting _anyway_. >>>> >> >>>> >> Last time I checked, the thread was talking about bare repository. >>> >>> Look at the subject. "Cloning empty repositories." >> >> Look at the content. "cloning a empty bare repository". > > But both of Johannes's points apply equally well to an empty > bare repository and to an empty non bare repository. IOW, > bareness does not matter to the suggestion Johannes gave. > > But you are acting as if the bareness of the target repository > makes his point irrelevant. I am a bit confused. > > About his point 1, I'd just stop at saying that "it is not so > hard" does not mean "we do not have to make it even easier". > > 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. Just a wild idea. Doesn't it make sense to introduce perfect ultimate common ancestor of the universe, probably calling it "the NULL commit"? At first glance it seems that it can help to avoid corner cases automagically. -- Sergei. - 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
