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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 20, 2016, 21:27 UTC
Message-ID: <xmqqshygt1gs.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kZMOv0r9fRFbP1WV8qFJBm+s=V8=ueFbYvnyFtgV8j9iQ@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 7 quoted lines

>> 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.