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