On Wed, Apr 20, 2016 at 8:22 AM, Yaroslav Halchenko <yoh@xxxxxxxxxxxxxx> wrote: > Dear Git Folks, > > I do realize that the situation is quite uncommon, partially I guess due > to git submodules mechanism flexibility and power on one hand and > under-use (imho) on the other, which leads to discovery of regressions > [e.g. 1] and corner cases as mine. Thanks for fixing the under-use and reporting bugs. :) > > [1] http://thread.gmane.org/gmane.comp.version-control.git/288064 > [2] http://www.onerussian.com/tmp/git-web-submodules.sh > > My use case: We are trying to serve a git repository with submodules > specified with relative paths over http from a simple web server. With a demo > case and submodule specification [complete script to reproduce including the > webserver using python is at 2] such as > > (git)hopa:/tmp/gitxxmsxYFO[master]git > $> tree > . > ├── f1 > └── sub1 > └── f2 > > $> cat .gitmodules > [submodule "sub1"] > path = sub1 > url = ./sub1 > > > 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. > > 2. If I serve the clone [2 demos that too] itself, there is no easy remedy at > all since sub1/.git is not a directory but a gitlink. Not sure I understand the second question. > > N.B. I haven't approached nested submodules case yet in [2] > > I wondered > > a. could 'git clone' (probably actually some relevant helper used by fetch > etc) acquire ability to sense for URL/.git if URL itself doesn't point to a > usable git repository? So you mean in case of relative submodules, we need to take the parent url, and remove the ".git" at the end and try again if we cannot find the submodule? > > I think this could provide complete remedy for 1 since then relative urls > would be properly assembled, with similar 'sensing' for /.git for the final urls > > I guess we could do it with rewrites/forwards on the "server side", > but it wouldn't be generally acceptable solution. > > b. is there a better or already existing way to remedy my situation? > > c. shouldn't "git clone" (or the relevant helper) be aware of remote > /.git possibly being a gitlink file within submodule? Oh. I think that non-bare repositories including submodules are not designed to be cloned, because they are for use in the file system. Even a local clone fails: # gerrit is a project I know which also has submodules: git clone --recurse-submodules https://gerrit.googlesource.com/gerrit g1 git clone --recurse-submodules g1 g2 ... fatal: clone of '...' into submodule path '...' failed So I think for cloning repositories you want to have each repository as its own thing (bare or non bare). The submodule mechanism is just a way to express a relation between the reositories, it's like composing them together, but by that composition it breaks the properties of each repository to be easily clonable. I think we should fix that. I guess the local clone case is 'easy' as you only need to handle the link instead of directory thing correctly. For the case you describe (cloning from a remote, whether it is http or ssh), we would need to discuss security implications I would assume? It sounds scary at first to follow a random git link to the outer space of the repository. (A similar thing is that you cannot have symlinks in a git repository pointing outside of it, IIRC? At least that was fishy.) Thanks, Stefan > > > Thank you in advance for your thoughts and feedback on this case. > > P.S. Please maintain the CC list in replies. > -- > Yaroslav O. Halchenko > Center for Open Neuroscience http://centerforopenneuroscience.org > Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 > Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 > WWW: http://www.linkedin.com/in/yarik > -- > 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 -- 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