On Tue, May 23, 2017 at 12:27 AM, Junio C Hamano <gits...@pobox.com> wrote: > Ævar Arnfjörð Bjarmason <ava...@gmail.com> 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
If the URL doesn't point to the canonical upstream how do we review a patch to update sha1dc here on list? Doesn't change from "'git am' this and it'll work" to "'git am' this and it'll fail, then do this submodule config modification dance, and run some other command....". I haven't tried repointing a submodule temporarily (and locally) to another URL for such a use, how is that even done? > 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. I had the same comments Stefan pointed out below about this. So I won't repeat any of that... > 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. If we were talking about any other project but git.git I'd say "yeah this makes sense". But I think in our case we should keep in mind the main point of this exercise is for us to dogfood submodule usage, not just so we get whatever trivial benefits from updating the sha1collision/ directory from upstream, but so that we run into issues with submodules that we solve for all our users. In this case you're basically concerned with: * We have N mirrors, but the upstream submodule URL is just one URL, so let's not point to that, but to our N mirrors Could also be addressed with a combination of 'pullUrl' for submodules (inverse of pushUrl for push) to list the canonical one & list of mirrors (or use the relative URL). * What if upstream say 5 years in the future rewinds their history, github shuts down or whatever, can we check out and work with older versions of git.git? Seems like it would be useful to have a way to ex-post-facto say "past history should use these URLs". i.e. if all git.git mirrors go down and we have to re-host, then you can just clone git.git and off you go, but the same isn't true of past submodule urls, or is it?
