Jack,
In my case it was enough to set the origin remote URL to the new one:
$ git remote --v
origin git://anongit.kde.org/kmymoney (fetch)
origin g...@git.kde.org:kmymoney (push)
$ git remote set-url origin g...@invent.kde.org:office/kmymoney.git
$ git remote --v
origin g...@invent.kde.org:office/kmymoney.git (fetch)
origin g...@invent.kde.org:office/kmymoney.git (push)
$ git pull
Already up to date.
I also had to add my SSH keys to my profile in GitLab, but other than that
it was fairly smooth.
On Sat, May 16, 2020 at 7:26 PM Jack <ostrof...@users.sourceforge.net>
wrote:
> The forwarded note includes "
> > To assist developers with the transition process, Sysadmin has
> > developed a utility ('git kpull') which once setup on a developers
> > system will automatically migrate any git.kde.org/anongit.kde.org to
> > the new structure automatically, before proceeding with a regular
> > 'git pull' when run in a Git repository.
> Does anyone know how to get this setup on a developers system? As I
> understand it, that really needs to be run within the two weeks after
> the migration to make the transition as easy as possible.
>
> Thanks for any pointers.
>
> Jack
>
> On 2020.05.15 13:38, Thomas Baumgart wrote:
> > Hi all,
> >
> > as already announced, the migration to the KDE Gitlab infrastructure
> > will happen this weekend. Please take a minute and read the
> > below information.
> >
> > Regards
> >
> > Thomas
> >
> > ---------- Forwarded Message ----------
> >
> > Subject: Notice regarding upcoming gitlab migration
> > Date: Freitag, 15. Mai 2020, 11:18:48 CEST
> > From: Bhushan Shah <bs...@mykolab.com>
> > To: kde-cvs-annou...@kde.org, sysad...@kde.org
> >
> > Good afternoon!
> >
> > This email is regarding the upcoming gitlab migration which sysadmins
> > are planning to action this weekend.
> >
> > -- Timeline --
> >
> > At the moment we are intending to perform a bulk migration of all
> > repositories from git.kde.org to invent.kde.org on 16 May 2020.
> >
> > We plan to start this migration from saturday 03:00 UTC / 05:00 CEST.
> > When this transition commences, git.kde.org and invent.kde.org will
> > be made read-only.
> >
> > Following this, the current system will be kept active in a read-only
> > configuration for two weeks (until 30 May 2020) to allow for everyone
> > to smoothly transition local clones and any automated systems over to
> > the new Gitlab setup.
> >
> > -- New releases --
> >
> > Since this migration also requires changes on the translation
> > infrastructure side, maintainers should not make new releases starting
> > from today until migration is completed on both source hosting and
> > translations infrastructure side.
> >
> > At this time we anticipate that complete update of the other
> > associated
> > infrastructure (including translations) may take up to a week and
> > therefore recommend that projects reschedule any releases (apart from
> > security fixes) to take place after 25 May 2020.
> >
> > -- Tooling --
> >
> > To assist developers with the transition process, Sysadmin has
> > developed a utility ('git kpull') which once setup on a developers
> > system will automatically migrate any git.kde.org/anongit.kde.org to
> > the new structure automatically, before proceeding with a regular 'git
> > pull' when run in a Git repository.
> >
> > Additionally, as some developers had concerns regarding locating
> > repositories, an additional utility known as 'git kclone' is being
> > shipped as well. This will allow developers to run "git kclone
> > <identifier>" to clone a repository.
> >
> > In the majority (95%) of cases we expect "<identifier>" to be
> > identical to the repository name (frameworks/kcoreaddons being
> > kcoreaddons for instance), however where the name is common (such as
> > 'dialer') then it will be prefixed by the name of the originating
> > project (so maui/dialer would have an identifier of maui-dialer)
> > following the convention we use at the moment for projects wishing to
> > have a repository using a common name.
> >
> > It should be noted that 'git kclone' is also able to perform bulk
> > clones based on wildcard patterns (which you could use to clone all
> > frameworks by running "git kclone frameworks/*" for example)
> >
> > Instructions on how to set this up on your system will be sent out
> > after the migration.
> >
> > -- Continuous Integration --
> >
> > Following the migration, we will continue to use our existing Jenkins
> > based setup. Migration to using Gitlab for CI purposes will take place
> > at a later date once the necessary adjustments to the CI
> > infrastructure have been completed.
> >
> > During the intervening time CI capability will be available on Gitlab
> > for evaluation and testing purposes only.
> >
> > This is not supported as a standard production level service by
> > Sysadmin and therefore should not be relied upon by projects as part
> > of their workflow.
> >
> > -- Tasks --
> >
> > Tasks will be migrated from Phabricator at a future point in time.
> > These will remain on Phabricator for the time being and are not
> > affected by the migration.
> >
> > Projects wishing to start entirely new boards and not needing to work
> > with existing boards on Phabricator should feel free to begin making
> > use of their new Gitlab boards following the migration.
> >
> > -- Migration from Phabricator --
> >
> > Existing code reviews will not be migrated from Phabricator as part of
> > this migration process and will need to be completed using the usual
> > process on Phabricator. It is expected that following the completion
> > of the migration of code hosting that no further new reviews will be
> > started on Phabricator.
> >
> > Please note that because Phabricator is dependent on the existing
> > git.kde.org/anongit.kde.org setup, once those are shutdown the hooks
> > that automatically close reviews will no longer operate.
> >
> > Tasks will be migrated in a future step, following which Phabricator
> > will be shutdown. Based on initial testing we expect to be able to
> > provide a static copy of Phabricator (for reviews only as tasks will
> > have been migrated at this stage) for long term archival purposes.
> >
> > -- Conclusion --
> >
> > Should anyone have any questions regarding the above, please let us
> > know
> > at sysad...@kde.org
> >
> > --
> > Bhushan Shah
> > KDE Sysadmin team
> > IRC Nick : bshah on Freenode
> > GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC
> > E11D
> >
> > -----------------------------------------
> > --
> >
> > Regards
> >
> > Thomas Baumgart
> >
> > https://www.signal.org/ Signal, the better WhatsApp
> > -------------------------------------------------------------
> > To be or not to be that is the question. - Any programmer
> > knows the answer: $2B | !$2B is $FF.
> > -------------------------------------------------------------
> >
>
>
