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

Erik Faye-Lund [off-list ref] writes:

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?

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?