Re: git checkout creates strange '(null)'-branch

From: Junio C Hamano <gitster@pobox.com>
Date: May 8, 2012, 16:22 UTC
Message-ID: <7vhavqy75q.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CABPQNSYzxDoer_Xhf+8EEU4zz58PLRQiZAsg_CWzP3ps6f_4rw@mail.gmail.com>

Erik Faye-Lund <kusmabite@gmail.com> writes:

Show 7 quoted lines

> Yes, it does. Basically, it calls "git checkout -f -q" from cmd_add if
> $branch is empty. And it fails if the checkout-call fails.
>
> I'm not saying it's a sane thing to do. But to me, it kind of feels
> natural to initialize the shared (i.e bare) repos for both the
> superproject and the submodule, clone the superproject, add the
> submodule, and populate these from there.

I sense a bit of slipperly slope here. After doing this, the superproject would have its .gitmodules file set up to point at something, but what does its first commit look like? Other files and .gitmodules, but no empty-submodule? Can you commit the superproject _with_ empty-submodule without having any commit in that empty-submodule? I think "git add" should fail when there is no commit there in the first place, so you won't create such a superproject commit that does not have anything in the submodule. Is that OK for everybody? Or would we add yet another funny special case for such a setting, perhaps by contaminating the index and the tree in the superproject with a stand-in value to represent a "does not yet exist" commit that ought to be at the tip of submodule's history?

Show 5 quoted lines

> But that won't work the way
> things currently are, because you can't "git submodule add" an empty
> project.
>
> To allow that,...

Yes, allowing that does not seem to make sense at all in the larger picture. What benefit would we get from that slipperly slope?