On Wed, Apr 20, 2016 at 12:51 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > >>> 1. After cloning >>> >>> git clone http://localhost:8080/.git >>> >>> I cannot 'submodule update' the sub1 in the clone since its url after >>> 'submodule init' would be http://localhost:8080/.git/sub1 . If I manually fix >>> it up -- it seems to proceed normally since in original repository I have >>> sub1/.git/ directory and not the "gitlink" for that submodule. >> >> So the expected URL would be http://localhost:8080/sub1/.git ? >> >> I thought you could leave out the .git prefix, i.e. you can type >> >> git clone http://localhost:8080 >> >> and Git will recognize the missing .git and try that as well. The relative URL >> would then be constructed as http://localhost:8080/sub1, which will use the >> same mechanism to find the missing .git ending. > > 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. I would imagine, if I have a problem with some repo I can tell my coworker or others to get my copy to took into that exact state. (Or I want to transfer state from workstation to laptop to continue working) Without submodules this workflow works. So I'd expect it to work with submodules as well eventually. Also we probably don't want to mix cloning the superproject from this non bare repo and the generic submodule locations as the superproject may have advanced submodule pointers to commits which are not present in the generic submodule remotes. So for the non-bare case I would really expect to be able to "copy" the remote including submodules from that remote? We could reason about only providing this for the superproject though and not for submodules, i.e. cloning from the non bare submodule could be not supported. (If you really want that non bare submodule, you can still clone it manually from $GIT_DIR_SUPER_PROJECT/modules/$MODULE_NAME > > These $submodule/.git files point via "gitdir:" to their real > repository location, don't they? Yes they do. > And I would think that they are > what you would want to expose to the outside world. Your in-tree > submodules may come and go as you checkout different branches in > your working tree, but these copies at their real locations will > stay. Right instead of cloning $WORKTREE/sub/.git you rather want $GITDIR/module/sub (GITDIR and WORKTREE from the superprojects point of view) The problem with a copy of a superproject including submodules is the way cloning submodules work. 1) clone the superproject 2) for each gitlink in the tree, consult the .gitmodules file 3) if we have a match in the .gitmodules file, clone from there So currently the protocol doesn't allow to even specify the submodules directories. In case the remote superproject is non bare in 1) the remote would need to advertise the submodule repository URLS separately, such that the cloning can be performed from those direct copies. Thanks, Stefan > > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html