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

[Junio C Hamano <gitster@pobox.com>]

Sergei Organov <osv@javad.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> 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.

The tools do not have problem with the multiple-root issue; we
can merge without common ancestor just fine.  So in that area,
we do not need to kludge like that at the physical level (you
can think of root commits having "the NULL" as their parents).

But cloning void to start the same project by multiple people
and pushing their initial commits as roots to start a project
indicates the lack of developer communication (besides, it just
feels like a bad style, a hangover from centralized SCM
mentality, but that is fine).

If the "feature" can be supported with zero cost, I do not have
a problem.  If that feature does something one does not agree
with (be it promoting a bad workflow or whatever), one does not
have to use it.  All one has to do is try not to recommend using
that feature to others.

But this time, the "feature" is not a zero cost thing.  As
Matthieu said in the thread, we do not let you do so right now.
Which means that it would involve new development, the code
changes would risk regressing behaviour existing users rely on,
and we would need testing for that.  These all take resources.

We already spent quite a lot of time on this thread, and at
least to me I feel that my time would have been better spent if
instead I were looking at patches on some other topics, or
working on cleaning up cherry-pick/revert implementation.