s/GitHub/GitLab/

5 files changed, 21 insertions, 21 deletions

diff --git a/.builds/alpine.yml b/.builds/alpine.yml
index e4c654b1..ab613b28 100644
--- a/.builds/alpine.yml
+++ b/.builds/alpine.yml
@@ -18,7 +18,7 @@ packages:
   - xwayland
   - libseat-dev
 sources:
-  - https://github.com/swaywm/wlroots
+  - https://gitlab.freedesktop.org/wlroots/wlroots.git
 tasks:
   - setup: |
       cd wlroots
diff --git a/.builds/archlinux.yml b/.builds/archlinux.yml
index 1c89ca6f..4d8e3767 100644
--- a/.builds/archlinux.yml
+++ b/.builds/archlinux.yml
@@ -19,7 +19,7 @@ packages:
   - vulkan-headers
   - glslang
 sources:
-  - https://github.com/swaywm/wlroots
+  - https://gitlab.freedesktop.org/wlroots/wlroots.git
 tasks:
   - setup: |
       cd wlroots
diff --git a/.builds/freebsd.yml b/.builds/freebsd.yml
index 368167c8..dc79d561 100644
--- a/.builds/freebsd.yml
+++ b/.builds/freebsd.yml
@@ -26,7 +26,7 @@ packages:
   - sysutils/seatd
   - gmake
 sources:
-  - https://github.com/swaywm/wlroots
+  - https://gitlab.freedesktop.org/wlroots/wlroots.git
 tasks:
   - wlroots: |
       cd wlroots
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index a4e53bbd..b63d8b4f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,21 +1,21 @@
 # Contributing to wlroots
 
-Contributing just involves sending a pull request. You will probably be more
+Contributing just involves sending a merge request. You will probably be more
 successful with your contribution if you visit [#sway-devel on Libera Chat]
 upfront and discuss your plans.
 
 Note: rules are made to be broken. Adjust or ignore any/all of these as you see
 fit, but be prepared to justify it to your peers.
 
-## Pull Requests
+## Merge Requests
 
-If you already have your own pull request habits, feel free to use them. If you
+If you already have your own merge request habits, feel free to use them. If you
 don't, however, allow me to make a suggestion: feature branches pulled from
 upstream. Try this:
 
 1. Fork wlroots
-2. `git clone git@github.com:<username>/wlroots.git && cd wlroots`
-3. `git remote add upstream https://github.com/swaywm/wlroots`
+2. `git clone git@gitlab.freedesktop.org:<username>/wlroots.git && cd wlroots`
+3. `git remote add upstream https://gitlab.freedesktop.org/wlroots/wlroots.git`
 
 You only need to do this once. You're never going to use your fork's master
 branch. Instead, when you start working on a feature, do this:
@@ -24,11 +24,11 @@ branch. Instead, when you start working on a feature, do this:
 2. `git checkout -b add-so-and-so-feature upstream/master`
 3. Add and commit your changes
 4. `git push -u origin add-so-and-so-feature`
-5. Make a pull request from your feature branch
+5. Make a merge request from your feature branch
 
-When you submit your pull request, your commit log should do most of the talking
+When you submit your merge request, your commit log should do most of the talking
 when it comes to describing your changes and their motivation. In addition to
-this, your pull request's comments will ideally include a test plan that the
+this, your merge request's comments will ideally include a test plan that the
 reviewers can use to (1) demonstrate the problem on master, if applicable and
 (2) verify that the problem no longer exists with your changes applied (or that
 your new features work correctly). Document all of the edge cases you're aware
@@ -80,15 +80,15 @@ cmd_move"* or *"Improve performance of arrange_windows on ARM"* or similar.
 
 The subsequent lines should be separated from the subject line by a single
 blank line, and include optional details. In this you can give justification
-for the change, [reference Github issues], or explain some of the subtler
+for the change, [reference issues], or explain some of the subtler
 details of your patch. This is important because when someone finds a line of
 code they don't understand later, they can use the `git blame` command to find
 out what the author was thinking when they wrote it. It's also easier to review
-your pull requests if they're separated into logical commits that have good
+your merge requests if they're separated into logical commits that have good
 commit messages and justify themselves in the extended commit description.
 
-As a good rule of thumb, anything you might put into the pull request
-description on Github is probably fair game for going into the extended commit
+As a good rule of thumb, anything you might put into the merge request
+description on GitLab is probably fair game for going into the extended commit
 message as well.
 
 See [How to Write a Git Commit Message] for more details.
@@ -101,16 +101,16 @@ changes will typically see review from several people. Be prepared to receive
 some feedback - you may be asked to make changes to your work. Our code review
 process is:
 
-1. **Triage** the pull request. Do the commit messages make sense? Is a test
+1. **Triage** the merge request. Do the commit messages make sense? Is a test
    plan necessary and/or present? Add anyone as reviewers that you think should
-   be there (using the relevant GitHub feature, if you have the permissions, or
+   be there (using the relevant GitLab feature, if you have the permissions, or
    with an @mention if necessary).
 2. **Review** the code. Look for code style violations, naming convention
    violations, buffer overflows, memory leaks, logic errors, non-portable code
    (including GNU-isms), etc. For significant changes to the public API, loop in
    a couple more people for discussion.
 3. **Execute** the test plan, if present.
-4. **Merge** the pull request when all reviewers approve.
+4. **Merge** the merge request when all reviewers approve.
 5. **File** follow-up tickets if appropriate.
 
 ## Style Reference
@@ -396,6 +396,6 @@ static void subsurface_handle_surface_destroy(struct wl_listener *listener,
 [#sway-devel on Libera Chat]: https://web.libera.chat/gamja/?channels=#sway-devel
 [linear, "recipe" style]: https://www.bitsnbites.eu/git-history-work-log-vs-recipe/
 [git-rebase.io]: https://git-rebase.io/
-[reference Github issues]: https://help.github.com/articles/closing-issues-via-commit-messages/
+[reference issues]: https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically
 [How to Write a Git Commit Message]: https://chris.beams.io/posts/git-commit/
 [kernel style]: https://www.kernel.org/doc/Documentation/process/coding-style.rst
diff --git a/README.md b/README.md
index 6af4e171..33c59104 100644
--- a/README.md
+++ b/README.md
@@ -75,9 +75,9 @@ Install like so:
 See [CONTRIBUTING.md].
 
 [Wayland]: https://wayland.freedesktop.org/
-[wiki]: https://github.com/swaywm/wlroots/wiki/Getting-started
+[wiki]: https://gitlab.freedesktop.org/wlroots/wlroots/-/wikis/Getting-started
 [#sway-devel on Libera Chat]: https://web.libera.chat/gamja/?channels=#sway-devel
 [Sway]: https://github.com/swaywm/sway
 [wrapper libraries]: https://github.com/search?q=topic%3Abindings+org%3Aswaywm&type=Repositories
 [libseat]: https://git.sr.ht/~kennylevinsen/seatd
-[CONTRIBUTING.md]: https://github.com/swaywm/wlroots/blob/master/CONTRIBUTING.md
+[CONTRIBUTING.md]: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/CONTRIBUTING.md