Update on Status of Gitlab Migration

[Michael Pyne]

On Sat, Apr 11, 2020 at 09:25:11PM +0200, Johan Ouwerkerk wrote:
> On Sat, Apr 11, 2020 at 8:39 PM Ben Cooksley <bcooksley at 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