Migrate ext/geoip to doc-extensions

[jordikroon]

The point of this PR is to migrate extensions from doc-en while preserving it's (linear) history.
The scope is to only add files that are listed in the reference folder.

Command to replicate:

git -C ../doc-en format-patch --root -o /path/to/patches -- reference/<ext>
git am --committer-date-is-author-date /path/to/patches/*.patch

This is still a draft. The next (possible) step would be to fix the XML entities. Also planning to do a docbook-cs sweep.

[jordikroon]

@lacatoire since you were planning to migrate a few extensions. This should be the way forward so we don't lose credibility towards contributors.

[jordikroon]

Okay scrap this. While it works, it's not practical for all extensions. It's best to migrate all the extensions at once code-wise. Without creating a PR.
Why, because it would preserve history without us either squashing.

If we were to use PRs and allow to merge with commits preserved, it would create a lot of duplicates as well.
So my approach would be as follows:

So the steps would be:

• Agree on the final list (see RFC, but let's double check)
• Migrate these extensions here
• Run docbook-cs on them
• Fix and migrate DTD entities to XML entities

CC @lacatoire, @alfsb and @NickSdot

[lacatoire]

Okay scrap this. While it works, it's not practical for all extensions. It's best to migrate all the extensions at once code-wise. Without creating a PR. Why, because it would preserve history without us either squashing.

If we were to use PRs and allow to merge with commits preserved, it would create a lot of duplicates as well. So my approach would be as follows:

So the steps would be:

* Agree on the final list (see RFC, but let's double check)

* Migrate these extensions here

* Run docbook-cs on them

* Fix and migrate DTD entities to XML entities

CC @lacatoire, @alfsb and @NickSdot

Damn, i was in the middle of doing them all of mine

[lacatoire]

@jordikroon i let you do this, don't have the permission to do it

[alfsb]

Why, because it would preserve history without us either squashing.

There is also "Rebase and merge", no squash involved. In theory, there will be no file conflicts, as extensions are imported per directory. But Commit Date is updated, AFAIK.

If we were to use PRs and allow to merge with commits preserved, it would create a lot of duplicates as well. So my approach would be as follows:

Duplication of hashes, duplication of contents, both?

In theory, doing per directory imports, direct in master and outside PRs, will allow using --committer-date-is-author-date, both in git am and git rebase, so each file name will show the correct chronology, even if the repository itself will have a non-linear chronology.

But as there are many transversal commits, that change many files in many directories, the only way I know to have a fully consistent chronological order at repository level is to make the import in one go.

That said, fixing everything in one go, while tempting, may not be viable. Possibly many "main manual" entities will need to be created, with different contents, and that will be a piecewise process.