Re: problems serving non-bare repos with submodules over http

Stefan Beller [off-list ref] writes:

quoted

I may be missing the subtleties, but if you are serving others from
a non-bare repository with submodules, I do not think you would want
to expose the in-tree version of the submodule in the first place.

Well I would imagine that is the exact point.
If I was not trying to expose my state, I could ask you to
obtain your copy from $(git remote get-url origin) just as I did.

That wasn't what I had in mind, but if the cloner cloned from your
repository with a working tree, the cloner would discover submodules
you use from your .gitmodules file, which would record the location
you cloned them from, so something like that may come into the
picture.  What I had in mind was more like this one you mentioned
below:

    $GIT_DIR_SUPER_PROJECT/modules/$MODULE_NAME
...
Right instead of cloning $WORKTREE/sub/.git you rather want
$GITDIR/module/sub

So currently the protocol doesn't allow to even specify the submodules
directories.

Depends on what you exactly mean by "the protocol", but the
networking protocol is about accessing a single repository.  It is
up to you to decide where to go next after learning what you can
learn from the result, typically by following what appears in
the .gitmodules file.

The only special case is when .gitmodules file records the URL in a
relative form, I would think.  Traditionally (i.e. when it was
considered sane to clone only from bare repositories) I think people
expected a layout like this:

	top.git/
	top.git/refs/{heads,tags,...}/...
        top.git/objects/...
        top.git/sub.git/
	top.git/sub.git/refs/{heads,tags,...}/...
        top.git/sub.git/objects/...

and refer to ./sub.git from .gitmodules recorded in top.git.  It
still would be norm for common distribution sites (i.e. the original
place Yaroslav likely has cloned things from) to be bare, and with
or without $GIT_DIR/modules/, the relative path of submodule seen
by its superproject would (have to) be different between a bare and
a non-bare repository.

I'd imagine that people could agree on a common layout like this
even for a forest of bare repositories:

	top.git/
	top.git/refs/{heads,tags,...}/...
        top.git/objects/...
        top.git/modules/sub.git/
	top.git/modules/sub.git/refs/{heads,tags,...}/...
        top.git/modules/sub.git/objects/...

which would probably make the "relative" relationship between the
supermodule and its submodules the same between bare and non-bare
repositories, but I didn't think it too deeply.