... > > As relative path I would propose $SUPERURL/subproject/$SUBPROJECTNAME, ie. > > if the superproject is at git://git.kernel.org/pub/super.git, the above > > subproject would default to the URL > > git://git.kernel.org/pub/super.git/subproject/linux24 which could be a > > symlink on the server. > > I'm really uncomfortable with the idea of relying on directory structure > passed the root repository path; from the > git://git.kernel.org/pub/super.git/ > point onwards; we don't have any right to expect that this is a real directory > tree. As an example; svn URLs don't match up with what's on disk: > > svn://svnhost/pub/repo/trunk/src > ^^^^^^^^^^ > > On disk there is no such directory as /trunk/src under the repository > directory. In the same way, even technically what you suggest would work, > the part of the URL under git://git.kernel.org/pub/super.git/ is git's own > namespace - it's not the users to mess with. E.g. if I had a subproject > called "refs" you'd be in trouble. Oh, that's easily solvable: just stick a 'subprojects' directory in there. That is, the default URL to find a subproject would be: 1. For non-bare repo foo/.git/, subproject bar will live in foo/bar/.git or foo/bar.git. 2. For a bare repo foo.git/, subproject bar will live in foo.git/subprojects/bar.git. > > > 2. Suppose .gitmodules in upstream tree points at subproject repo at > > > kernel.org, and I clone from there - my repo will point at kernel.org by > > > default? But now, I'd like everyone who clones from *my* repo to get > > > pointed at *my* server by default (e.g. for mirroring), > > > but would not changing .gitmodules create a commit so my > > > head will now differ from upstream - so it won't be signed properly > > > etc... Did I misunderstand something? > > > > No, that is correct. Supporting a relative URL specification as proposed > > above should solve this issue. > > I think that's the wrong solution. A change of source URL for a submodule > from what upstream uses to your own server is a _fork_ from upstream, > therefore you would fork your own branch in your supermodule and > alter .gitmodules to point at your server. Everybody is happy, and the fork > is recorded. Why should I record it? If the content is the same, the commit name should be the same, it shouldn't matter where did the content came from. I wouldn't be happy: I have just cloned both project and superproject, but to re-publish the superproject using my clone of subproject, I have to create a new commit, which would have a different hash from the origin. So how do people know they can trust my tree? And what happens when the original super-project pulls from me - it seems that his .gitmodules will now point to my server? > The override system is only there for the local repository (which always takes > precedence) not for the server provider to hide detail from those checking > the repo out. I really like it that currently, in git, there is no difference between a public and local repository. If the override system is only for the local repository, we create a difference here - doesn't this break the distributed nature of git? Take offline work as an example: So I have have cloned the supermodule and the submodule to my laptop - it's enough to edit .git/config and I can use the history locally - that's good. But now I try to clone the local tree - and a clone will try to go out to the URL which I cloned - bad. -- MST - 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
