On Sat, Apr 11, 2020 at 09:25:11PM +0200, Johan Ouwerkerk wrote: > On Sat, Apr 11, 2020 at 8:39 PM Ben Cooksley <bcooks...@kde.org> wrote: > > > > Yes, the hostname git.kde.org will be fully retired as part of this > > transition. > > > > From my understanding kdesrc-build will automatically pick this up > > once we update sysadmin/repo-metadata to show the new repository > > paths. > > This is something we'll confirm with mpyne though to ensure we can > > make the cutover as smooth as possible. > > > > Just to be clear, my understanding based on reading the > `Updated/Git.pm` module is that KDE repo paths are abstracted via > ~/.gitconfig URL remapping using `insteadOf`and `pushInsteadOf`. > Currently the code manipulates the user's ~/.gitconfig to bind the > correct mappings to the `kde:` prefix (this happens even before > cloning sysadmin repos for metadata). > > So if my understanding of the code is correct, the entire switch over > is transparent provided that kdesrc-build is updated beforehand to set > the updated value for `pushInsteadOf`. We already have the same > mechanism in place in kdesrc-build for ensuring that people use > https://anongit.kde.org instead of git://anongit.kde.org when > cloning/fetching.
Yeah, when Ben asked me a couple of months back about it, this was the same conclusion I reached after reviewing the existing code. But I need to note that the way this works right now is that a module is cloned via a URL such as 'kde:juk' (not kde:kde/kdemultimedia/juk!). This is transparent to how git operates when setup with ~/.gitconfig, so you won't notice it in `git remote -v`, you need to actually look at the repository's .git/config, or run `git config --local --get remote.origin.url` in the source directory, to see whether it uses a kde: URL or a full URL. Either way, once the switchover happens, then *in theory* it can be as easy as running kdesrc-build once (to update ~/.gitconfig) and from there Git will rewrite to the updated URL automatically. We could add the switchover logic before that and guard it with a date check, that way we can do some testing early. > > Depending on how things look we may also make available a script that > > will update the configuration of a repository to reflect both the > > change in hostname as well as the change in path. > > > > A cleanup script could be handy. I think kdesrc-build will > automatically pick up new repo paths from metadata and that should > work transparently, but the old clones may get left behind as well. > People who use the kdesrc-build option to ignore KDE repo structure > shouldn't be affected at all. I don't know that we'll even necessarily need a cleanup script (though it couldn't hurt). In my case, my entire source repository contains only one repository directly referencing anongit (or git.kde.org), all others are non-KDE or kde: 1 git://anongit.kde.org/scratch/ 1 git://cmake.org/ 16 git://code.qt.io/ 1 git://git.freedesktop.org/ 1 git://git.gnupg.org/ 3 git://github.com/ 23 https://code.qt.io/ 7 https://github.com/ 1 https://gitlab.com/ 344 kde: All of the kde: repositories use the kde:foo syntax, where the 'foo' comes from the 'repopath' parameter of the sysadmin/repo-metadata YAML files. We may need to do on-the-fly conversion of the kde: repo paths if they won't be expressible as 'kde:foo' in the future, but we should have the information needed to do this in kdesrc-build to make this happen on-the-fly. Regards, - Michael Pyne