Re: Bug: "git checkout -b" should be allowed in empty repo

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Jan 31, 2012, 16:32 UTC
Message-ID: <4F281780.1070804@alum.mit.edu>
In-Reply-To: <m3k448che9.fsf@localhost.localdomain>

On 01/31/2012 11:09 AM, Jakub Narebski wrote:

> I don't see how this can be done in backward-compatibile way.

Yes, backwards compatibility would probably prevent the NULL commit idea from ever being implemented in a literal way.

But it is conceivable that it could be faked with some strategic

    if sha1 == '0'*40:
        treat_as_special_null_commit
    elif len(parents) == 0:
        parents = ['0'*40]

In other words, include a little special case fakery in the data structures near root commits (an O(1) amount of work) to avoid special cases in all commands that can touch root commits (an O(number of commands) amount of work).

Alternatively, the NULL commit could be a UI construct that has no manifestation in the object model. This would not save implementation work, but would perhaps give a more consistent way to deal with root commits in the UI than the current array of --orphan etc. options.

> Please note that in Git it is quite natural to have more than one root
> (parentless) commit, even without presence of disconnected / orphan
> branches.  They are result of joining originally separate projects.
> git.git has quite a few of them (more than 6, IIRC).

I don't see the problem, unless you mean that it would be difficult to merge repositories that don't link back to a NULL commit with hypothetical future repositories that do include a NULL commit. But a world in which two kinds of repositories have to be supported is pointless anyway, because then the git code would have to include *both* kinds of special cases and nothing would be gained.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/