Use caret shorthand to open links in new tab

Author: HonkingGoose

book/01-introduction/sections/about-version-control.asc

@@ -23,7 +23,7 @@ To deal with this issue, programmers long ago developed local VCSs that had a si
 image::images/local.png[Local version control diagram]
 
 One of the most popular VCS tools was a system called RCS, which is still distributed with many computers today.
-https://www.gnu.org/software/rcs/[RCS] works by keeping patch sets (that is, the differences between files) in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.
+https://www.gnu.org/software/rcs/[RCS^] works by keeping patch sets (that is, the differences between files) in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches.
 
 ==== Centralized Version Control Systems
 

book/01-introduction/sections/help.asc

@@ -18,7 +18,7 @@ $ git help config
 ----
 
 These commands are nice because you can access them anywhere, even offline.
-If the manpages and this book aren't enough and you need in-person help, you can try the `#git`, `#github`, or `#gitlab` channels on the Libera Chat IRC server, which can be found at https://libera.chat/[].
+If the manpages and this book aren't enough and you need in-person help, you can try the `#git`, `#github`, or `#gitlab` channels on the Libera Chat IRC server, which can be found at https://libera.chat/[^].
 These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help.(((IRC)))
 
 In addition, if you don't need the full-blown manpage help, but just need a quick refresher on the available options for a Git command, you can ask for the more concise "`help`" output with the `-h` option, as in:

book/01-introduction/sections/installing.asc

@@ -29,7 +29,7 @@ If you're on a Debian-based distribution, such as Ubuntu, try `apt`:
 $ sudo apt install git-all
 ----
 
-For more options, there are instructions for installing on several different Unix distributions on the Git website, at https://git-scm.com/download/linux[].
+For more options, there are instructions for installing on several different Unix distributions on the Git website, at https://git-scm.com/download/linux[^].
 
 ==== Installing on macOS
 
@@ -46,7 +46,7 @@ $ git --version
 If you don't have it installed already, it will prompt you to install it.
 
 If you want a more up to date version, you can also install it via a binary installer.
-A macOS Git installer is maintained and available for download at the Git website, at https://git-scm.com/download/mac[].
+A macOS Git installer is maintained and available for download at the Git website, at https://git-scm.com/download/mac[^].
 
 .Git macOS Installer
 image::images/git-osx-installer.png[Git macOS installer]
@@ -55,10 +55,10 @@ image::images/git-osx-installer.png[Git macOS installer]
 
 There are also a few ways to install Git on Windows.(((Windows, installing)))
 The most official build is available for download on the Git website.
-Just go to https://git-scm.com/download/win[] and the download will start automatically.
-Note that this is a project called Git for Windows, which is separate from Git itself; for more information on it, go to https://gitforwindows.org[].
+Just go to https://git-scm.com/download/win[^] and the download will start automatically.
+Note that this is a project called Git for Windows, which is separate from Git itself; for more information on it, go to https://gitforwindows.org[^].
 
-To get an automated installation you can use the https://chocolatey.org/packages/git[Git Chocolatey package].
+To get an automated installation you can use the https://chocolatey.org/packages/git[Git Chocolatey package^].
 Note that the Chocolatey package is community maintained.
 
 ==== Installing from Source
@@ -87,7 +87,7 @@ $ sudo apt-get install asciidoc xmlto docbook2x
 
 [NOTE]
 ====
-Users of RHEL and RHEL-derivatives like CentOS and Scientific Linux will have to https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F[enable the EPEL repository] to download the `docbook2X` package.
+Users of RHEL and RHEL-derivatives like CentOS and Scientific Linux will have to https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F[enable the EPEL repository^] to download the `docbook2X` package.
 ====
 
 If you're using a Debian-based distribution (Debian/Ubuntu/Ubuntu-derivatives), you also need the `install-info` package:
@@ -114,7 +114,7 @@ $ sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi
 due to binary name differences.
 
 When you have all the necessary dependencies, you can go ahead and grab the latest tagged release tarball from several places.
-You can get it via the kernel.org site, at https://www.kernel.org/pub/software/scm/git[], or the mirror on the GitHub website, at https://github.com/git/git/releases[].
+You can get it via the kernel.org site, at https://www.kernel.org/pub/software/scm/git[], or the mirror on the GitHub website, at https://github.com/git/git/releases[^].
 It's generally a little clearer what the latest version is on the GitHub page, but the kernel.org page also has release signatures if you want to verify your download.
 
 Then, compile and install:

book/02-git-basics/sections/recording-changes.asc

@@ -254,7 +254,7 @@ doc/**/*.pdf
 
 [TIP]
 ====
-GitHub maintains a fairly comprehensive list of good `.gitignore` file examples for dozens of projects and languages at https://github.com/github/gitignore[] if you want a starting point for your project.
+GitHub maintains a fairly comprehensive list of good `.gitignore` file examples for dozens of projects and languages at https://github.com/github/gitignore[^] if you want a starting point for your project.
 ====
 
 [NOTE]

book/04-git-server/sections/generating-ssh-key.asc

@@ -54,4 +54,4 @@ mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
 NrRFi9wrf+M7Q== [email protected]
 ----
 
-For a more in-depth tutorial on creating an SSH key on multiple operating systems, see the GitHub guide on SSH keys at https://docs.github.com/en/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent[].
+For a more in-depth tutorial on creating an SSH key on multiple operating systems, see the GitHub guide on SSH keys at https://docs.github.com/en/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent[^].

book/04-git-server/sections/gitlab.asc

@@ -19,7 +19,7 @@ The other installation options are:
 * From the source files.
 * Cloud provider such as AWS, Google Cloud Platform, Azure, OpenShift and Digital Ocean.
 
-For more information read the https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/README.md[GitLab Community Edition (CE) readme].
+For more information read the https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/README.md[GitLab Community Edition (CE) readme^].
 
 ==== Administration
 

book/04-git-server/sections/hosted.asc

@@ -5,6 +5,6 @@ Doing so offers a number of advantages: a hosting site is generally quick to set
 Even if you set up and run your own server internally, you may still want to use a public hosting site for your open source code – it's generally easier for the open source community to find and help you with.
 
 These days, you have a huge number of hosting options to choose from, each with different advantages and disadvantages.
-To see an up-to-date list, check out the GitHosting page on the main Git wiki at https://git.wiki.kernel.org/index.php/GitHosting[].
+To see an up-to-date list, check out the GitHosting page on the main Git wiki at https://git.wiki.kernel.org/index.php/GitHosting[^].
 
 We'll cover using GitHub in detail in <<ch06-github#ch06-github>>, as it is the largest Git host out there and you may need to interact with projects hosted on it in any case, but there are dozens more to choose from should you not want to set up your own Git server.

book/04-git-server/sections/protocols.asc

@@ -7,7 +7,7 @@ Here we'll discuss what they are and in what basic circumstances you would want
 
 (((protocols, local)))
 The most basic is the _Local protocol_, in which the remote repository is in another directory on the same host.
-This is often used if everyone on your team has access to a shared filesystem such as an https://en.wikipedia.org/wiki/Network_File_System[NFS] mount, or in the less likely case that everyone logs in to the same computer.
+This is often used if everyone on your team has access to a shared filesystem such as an https://en.wikipedia.org/wiki/Network_File_System[NFS^] mount, or in the less likely case that everyone logs in to the same computer.
 The latter wouldn't be ideal, because all your code repository instances would reside on the same computer, making a catastrophic loss much more likely.
 
 If you have a shared mounted filesystem, then you can clone, push to, and pull from a local file-based repository.
@@ -82,7 +82,7 @@ Instead of having to set up different URLs for these things, you can now use a s
 If you try to push and the repository requires authentication (which it normally should), the server can prompt for a username and password.
 The same goes for read access.
 
-In fact, for services like GitHub, the URL you use to view the repository online (for example, https://github.com/schacon/simplegit[]) is the same URL you can use to clone and, if you have access, push over.
+In fact, for services like GitHub, the URL you use to view the repository online (for example, https://github.com/schacon/simplegit[^]) is the same URL you can use to clone and, if you have access, push over.
 
 ===== Dumb HTTP
 

book/04-git-server/sections/smart-http.asc

@@ -68,5 +68,5 @@ You can do this with nearly any CGI-capable web server, so go with the one that
 
 [NOTE]
 ====
-For more information on configuring authentication in Apache, check out the Apache docs here: https://httpd.apache.org/docs/current/howto/auth.html[]
+For more information on configuring authentication in Apache, check out the Apache docs here: https://httpd.apache.org/docs/current/howto/auth.html[^]
 ====

book/05-distributed-git/sections/contributing.asc

@@ -60,7 +60,7 @@ Getting in the habit of creating quality commit messages makes using and collabo
 As a general rule, your messages should start with a single line that's no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation.
 The Git project requires that the more detailed explanation include your motivation for the change and contrast its implementation with previous behavior -- this is a good guideline to follow.
 Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug."
-Here is a template you can follow, which we've lightly adapted from one https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[originally written by Tim Pope]:
+Here is a template you can follow, which we've lightly adapted from one https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[originally written by Tim Pope^]:
 
 [source,text]
 ----
@@ -154,7 +154,7 @@ To jessica@githost:simplegit.git
 The last line of the output above shows a useful return message from the push operation.
 The basic format is `<oldref>..<newref> fromref -> toref`, where `oldref` means the old reference, `newref` means the new reference, `fromref` is the name of the local reference being pushed, and `toref` is the name of the remote reference being updated.
 You'll see similar output like this below in the discussions, so having a basic idea of the meaning will help in understanding the various states of the repositories.
-More details are available in the documentation for https://git-scm.com/docs/git-push[git-push].
+More details are available in the documentation for https://git-scm.com/docs/git-push[git-push^].
 
 Continuing with this example, shortly afterwards, John makes some changes, commits them to his local repository, and tries to push them to the same server: