Mac → macOS

completes progit#1161 and fixes progit#1197

book/01-introduction/sections/installing.asc

@@ -33,7 +33,7 @@ For more options, there are instructions for installing on several different Uni
 
 ==== Installing on macOS
 
-(((Mac, installing)))
+(((macOS, installing)))
 There are several ways to install Git on a Mac.
 The easiest is probably to install the Xcode Command Line Tools.(((Xcode)))
 On Mavericks (10.9) or above you can do this simply by trying to run 'git' from the Terminal the very first time.
@@ -51,9 +51,9 @@ A macOS Git installer is maintained and available for download at the Git websit
 .Git macOS Installer.
 image::images/git-osx-installer.png[Git macOS installer.]
 
-You can also install it as part of the GitHub for Mac install.
+You can also install it as part of the GitHub for macOS install.
 Their GUI Git tool has an option to install command line tools as well.
-You can download that tool from the GitHub for Mac website, at https://desktop.github.com[].
+You can download that tool from the GitHub for macOS website, at https://desktop.github.com[].
 
 ==== Installing on Windows
 

book/02-git-basics/sections/getting-a-repository.asc

@@ -18,7 +18,7 @@ for Linux:
 ----
 $ cd /home/user/my_project
 ----
-for Mac:
+for macOS:
 [source,console]
 ----
 $ cd /Users/user/my_project

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

@@ -19,7 +19,7 @@ config            id_dsa.pub
 
 You're looking for a pair of files named something like `id_dsa` or `id_rsa` and a matching file with a `.pub` extension.
 The `.pub` file is your public key, and the other file is the corresponding private key.
-If you don't have these files (or you don't even have a `.ssh` directory), you can create them by running a program called `ssh-keygen`, which is provided with the SSH package on Linux/Mac systems and comes with Git for Windows:
+If you don't have these files (or you don't even have a `.ssh` directory), you can create them by running a program called `ssh-keygen`, which is provided with the SSH package on Linux/macOS systems and comes with Git for Windows:
 
 [source,console]
 ----

book/04-git-server/sections/git-on-a-server.asc

@@ -5,7 +5,7 @@ Now we'll cover setting up a Git service running these protocols on your own ser
 
 [NOTE]
 ====
-Here we'll be demonstrating the commands and steps needed to do basic, simplified installations on a Linux-based server, though it's also possible to run these services on Mac or Windows servers.
+Here we'll be demonstrating the commands and steps needed to do basic, simplified installations on a Linux-based server, though it's also possible to run these services on macOS or Windows servers.
 Actually setting up a production server within your infrastructure will certainly entail differences in security measures or operating system tools, but hopefully this will give you the general idea of what's involved.
 ====
 

book/08-customizing-git/sections/attributes.asc

@@ -17,7 +17,7 @@ You'll see how to tell Git which is which.
 ===== Identifying Binary Files
 
 Some files look like text files but for all intents and purposes are to be treated as binary data.
-For instance, Xcode projects on the Mac contain a file that ends in `.pbxproj`, which is basically a JSON (plain-text JavaScript data format) dataset written out to disk by the IDE, which records your build settings and so on.
+For instance, Xcode projects on macOS contain a file that ends in `.pbxproj`, which is basically a JSON (plain-text JavaScript data format) dataset written out to disk by the IDE, which records your build settings and so on.
 Although it's technically a text file (because it's all UTF-8), you don't want to treat it as such because it's really a lightweight database – you can't merge the contents if two people change it, and diffs generally aren't helpful.
 The file is meant to be consumed by a machine.
 In essence, you want to treat it like a binary file.

book/08-customizing-git/sections/config.asc

@@ -245,11 +245,11 @@ You can also set up a graphical merge-conflict-resolution tool instead of having
 We'll demonstrate setting up the Perforce Visual Merge Tool (P4Merge) to do your diffs and merge resolutions, because it's a nice graphical tool and it's free.
 
 If you want to try this out, P4Merge works on all major platforms, so you should be able to do so.
-We'll use path names in the examples that work on Mac and Linux systems; for Windows, you'll have to change `/usr/local/bin` to an executable path in your environment.
+We'll use path names in the examples that work on macOS and Linux systems; for Windows, you'll have to change `/usr/local/bin` to an executable path in your environment.
 
 To begin, https://www.perforce.com/product/components/perforce-visual-merge-and-diff-tools[download P4Merge from Perforce].
 Next, you'll set up external wrapper scripts to run your commands.
-We'll use the Mac path for the executable; in other systems, it will be where your `p4merge` binary is installed.
+We'll use the macOS path for the executable; in other systems, it will be where your `p4merge` binary is installed.
 Set up a merge wrapper script named `extMerge` that calls your binary with all the arguments provided:
 
 [source,console]
@@ -388,7 +388,7 @@ Git has a few configuration options to help with these issues.
 
 (((crlf)))(((line endings)))
 If you're programming on Windows and working with people who are not (or vice-versa), you'll probably run into line-ending issues at some point.
-This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character.
+This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas macOS and Linux systems use only the linefeed character.
 This is a subtle but incredibly annoying fact of cross-platform work; many editors on Windows silently replace existing LF-style line endings with CRLF, or insert both line-ending characters when the user hits the enter key.
 
 Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem.
@@ -400,15 +400,15 @@ If you're on a Windows machine, set it to `true` -- this converts LF endings int
 $ git config --global core.autocrlf true
 ----
 
-If you're on a Linux or Mac system that uses LF line endings, then you don't want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it.
+If you're on a Linux or macOS system that uses LF line endings, then you don't want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it.
 You can tell Git to convert CRLF to LF on commit but not the other way around by setting `core.autocrlf` to input:
 
 [source,console]
 ----
 $ git config --global core.autocrlf input
 ----
 
-This setup should leave you with CRLF endings in Windows checkouts, but LF endings on Mac and Linux systems and in the repository.
+This setup should leave you with CRLF endings in Windows checkouts, but LF endings on macOS and Linux systems and in the repository.
 
 If you're a Windows programmer doing a Windows-only project, then you can turn off this functionality, recording the carriage returns in the repository by setting the config value to `false`:
 

book/A-git-in-other-environments/sections/guis.asc

@@ -66,15 +66,15 @@ Then you can simply stage or unstage some changes, alter the commit message, and
 `gitk` and `git-gui` are examples of task-oriented tools.
 Each of them is tailored for a specific purpose (viewing history and creating commits, respectively), and omit the features not necessary for that task.
 
-==== GitHub for Mac and Windows
+==== GitHub for macOS and Windows
 
-(((GitHub for Mac)))(((GitHub for Windows)))
+(((GitHub for macOS)))(((GitHub for Windows)))
 GitHub has created two workflow-oriented Git clients: one for Windows, and one for macOS.
 These clients are a good example of workflow-oriented tools – rather than expose _all_ of Git's functionality, they instead focus on a curated set of commonly-used features that work well together.
 They look like this:
 
-.GitHub for Mac.
-image::images/github_mac.png[GitHub for Mac.]
+.GitHub for macOS.
+image::images/github_mac.png[GitHub for macOS.]
 
 .GitHub for Windows.
 image::images/github_win.png[GitHub for Windows.]
@@ -96,7 +96,7 @@ While they're designed to highlight GitHub's service and recommended workflow, t
 
 ===== Installation
 
-GitHub for Windows can be downloaded from https://windows.github.com[], and GitHub for Mac from https://mac.github.com[].
+GitHub for Windows can be downloaded from https://windows.github.com[], and GitHub for macOS from https://mac.github.com[].
 When the applications are first run, they walk you through all the first-time Git setup, such as configuring your name and email address, and both set up sane defaults for many common configuration options, such as credential caches and CRLF behavior.
 
 Both are ``evergreen'' – updates are downloaded and installed in the background while the applications are open.