Aaaand, we are back with the universal "you shouldn't need that" GIT solution to all problems. Seriously, they should just throw away the manual, and print that on a single sheet in big letters.
There is a reason why it's Github, Gitee and Gitlab and not SVNHub or SVNLab. 
Just accept that git is better and has won. Nobody except some old white men will remember SVN in a few years - nobody will cry about that. Period.
Even then there is a choice between doing an haphazard migration now and waiting a few years till they finally get their act together. (and I'm not even so sure about that, it might be that github 10 years in the future will be like sf now).
Maybe then its users will actually be able to give to the point details, instead of just banging on about how popular it is and you shouldn't want anything else.
fpc main server will stay using svn.
There are too much problems to do the conversion to git with very little advantage.
If someone is against something, he will always find something which prevents it.
That is a gross oversimplification. But it also works the other way, people sometimes overlook the details if they have a real big drive for something.
Anyway, in my case there are multiple levels of against it. Most have been said. My original position was that I always thought it was too much work for benefit, but assumed git was a netto plus (which I mainly considered to be better merging and the more seamless offline work of a DVCS). With the losing of global revisions and more cmdline actions for a small fix as main productivity sacrifices/problems.
There was a majority of devels in favour of looking into GIT and a migration about an year ago. The wiki page about the migration is mostly my initial list of SVN features used that needed equivalents in GIT.
Some had been (allegedly) fixed, like per repo CRLF handling (older GIT needed manual client configuration, which was a risk, one of the reasons we migrated from CVS to SVN).
Losing global rev still hurts, and IMHO guids are unwieldy but maybe with something webbased linked to it, it will work out, and strictly speaking global revs also always needed branch as context in some cases, though that usually wasn't the problem, with only a handful of SVN branches (trunk,fixes) in multi-user use.
That left (to my surprise) the merge history stuff. I never expected a newer VCS to have a problem there, it was only on my list to have the alternative investigated before rather than after the migration.
But now we are a full year further, with all kinds of advocates writing lengthy posts and mails on it, and still we are not further than stuffing it manually in commit messages, and then writing software to string it together and that that is normal because GIT is so popular and you shouldn't want to have it any different way.
That is not progress, that is regression.
But it would be great if somebody (you) take care (administrator) of the fpc GitHub and GitLab mirrored site.
For example, if somebody does a pull request, you transform this into a svn patch and sent it to fpc-svn.
This won't work. A very large percentage of the patches are tossed back to the users for rewrite/cleanup. This is much harder with push/pull requests and at that point the history is toast anyway. The ones that apply cleanly and unmodified (my guess: about a third) are the trivial ones that work with any VCS system.
It is no use saying you accept pull requests if you have to reject all of them, except from some usual suspects that could do it either way. Maybe a merge request size limit for pull requests would put some onus on the submitter to only submit doable requests(iow only for trivial one line stuff), but that would probably require gitlab hacking etc again.
Also, the cloud stuff never will be anything but a mirror. The central server will still be locally owned gitlab setup.
This may work with new languages with all new codebases directly in the advocated style, but with a 50 years old multi dialect language with many styles in circulation, AND leaning on submissions for expansions in many aspects of the project, it is different. Just be a bit flexible, being so rigid makes you look old
omfg - telling me to be flexible but being a stubborn yourself? 
As said I'm pretty lax as it comes to coding styles. That I say no to a hopeless project like rearrange everything stylewise, write long documents to nail down the coding style to every last detail, build an automated custom framework to enforce it and then keep supporting it and discussing it ad infinitum doesn't mean I'm automatically an old stubborn ass in this.
It is simply pragmatism. At the very least before you start converting 10M lines of projects worth to such setup it should be fully production tested in a smaller but not trivial project.
And as far as stubbornness wrt GIT goes, I do know the project intimately after 20 years, and I studied GIT at least somewhat and tracked the discussions for 5 years+. I also come with arguments that are more than a simple popularity contest, or idealist advocacy copied right from the web. So please get off your high horse and do the same.
It's simply a mistake that nobody in the beginning defined a coding standard. Not my failure as I wasn't involved in this mistake - just here now to tell you that someone made a mistake and seems nobody feels responsible to solve it!
No, you are declaring it a mistake to justify your urgent need to nail down codestyle and converters. That is a choice not a decree that fell down from the heavens.
And I don't agree with that choice.
If you want to gain useful experience for a corporate career, I suggest to tackle that. Learn to cooperate, learn to adapt, learn to bear responsibility and most of all DO PRODUCTIVE WORK. Everybody can stand to the side and find something to complain about, but that is not productive.
Nobody who is really doing productive work works with methods from 1990. Especially in software development.
Hahaha, you would be surprised what old crap you encounter outside a few shiny new tech giants.
The website is less of a "could be changed", but more of a "is the change really really necessary?"
For me that sounds like: nothing is going to be changed!
Very few serious things have been suggested. Only knee-jerk suggestions to copy and paste fashionable setups without any looking into how FPC/Lazarus is organized and what its needs are. Basically redrawing the whole infrastructure on the back of a beercoasters in 5 minutes flat, while dozens work with a multitude of scenarios with the current setup, where processes and setup have matured together for several years. Replacing one piece is already a big undertaking.
Proposals often also conflict, e.g. arguing to use 3rd party services and arguing the very next message that a problem can be fixed with (server) software modification/customization.
It is hard to take such comments seriously, specially in cases when additional prodding doesn't get any more details, and only expands the magnitude of the changes rather than rein them in (like making a discussion about VCS into an infrastructure of enforcing code styles)
I dared you to come up with a functional mergetracking setup for GIT, and you came back with a quickly looked up command (which didn't solve it) and then quietly sidestepped the issue from then on, and continued on the tired old "it is more popular" "you are old" trajectories. Typical.
Agreed, if you contribute something you should also take care its getting documented properly. Otherwise its useless if nobody knows about it or knows how to use it.
You don't always know the full scope. Major functionality is often created in trajectories of an year and longer, and then some more before it comes into endusers hand.
Like the codeformatting discussion, such oversimplified mantras often don't work. But still I think there could be some improvement there (and there have been in the past, e.g. the userchanges pages). New features should at least be written down anywhere, with some pointers for documenters.
Recent
