Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > I liked the suggestion to make the URL a relative path, but this would > require you to maintain a mirror in the same places you push git.git > to, is that something you'd be willing to do? After thinking about this a bit more, I know what I think we want a bit better. Relative URL (e.g. ../sha1collisiondetection that sits next to the copy of git.git) may be a good way to go. I can arrange to create necessary repository next to git.git on k.org and github.com but I need to double check about other places Whether the submodule is referenced by a relative URL from the main project, the submodule should not come directly from the upstream, and various mirrors that sit next to git.git should not be blind and automated "mirrors". This is because I do not want us to trust the security measures of https://github.com/cr-marcstevens/ repository. The consumers already need to trust k.org/pub/scm/git/git.git and by ensuring k.org/pub/scm/git/sha1dc is managed the same way, they do not have to trust anything extra. Another reason is that we want to make sure all commits in the submodule that we bind to the superproject (i.e. git.git) are always in the submodule, regardless of what our upstream does, and one way to do so is to have control over _our_ canonical repository for the submodule. In normal times, it will faithfully follow the upstream without doing anything else, but we'd keep the option of anchoring a submodule commit that is referenced by the superproject history with our own tag, if it is ever rewound away in the upstream history for whatever reason. Thanks.