Polish for chapter 1

Author: ben

en/book/01-introduction/chapter1.asc

@@ -21,24 +21,22 @@ Many people’s version-control method of choice is to copy files into another d
 This approach is very common because it is so simple, but it is also incredibly error prone.
 It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to.
 
-To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control (see <<local_version_control>>).
+To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control.
 
-[[local_version_control]]
 .Local version control.
 image::images/18333fig0101-tn.png[Local version control diagram]
 
-One of the more popular VCS tools was a system called rcs, which is still distributed with many computers today.
-Even the popular Mac OS X operating system includes the  rcs command when you install the Developer Tools.
-This tool basically works by keeping patch sets (that is, the differences between files) from one change to another 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.
+One of the more popular VCS tools was a system called RCS, which is still distributed with many computers today.
+Even the popular Mac OS X operating system includes the `rcs` command when you install the Developer Tools.
+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 (((version control,centralized version control)))
 
 The next major issue that people encounter is that they need to collaborate with developers on other systems.
 To deal with this problem, Centralized Version Control Systems (CVCSs) were developed.
 These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place.
-For many years, this has been the standard for version control (see <<central_version_control>>).
+For many years, this has been the standard for version control.
 
-[[central_version_control]]
 .Centralized version control.
 image::images/18333fig0102-tn.png[Centralized version control diagram]
 
@@ -49,17 +47,16 @@ Administrators have fine-grained control over who can do what; and it’s far ea
 However, this setup also has some serious downsides.
 The most obvious is the single point of failure that the centralized server represents.
 If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on.
-If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything–the entire history of the project except whatever single snapshots people happen to have on their local machines.
-Local VCS systems suffer from this same problem–whenever you have the entire history of the project in a single place, you risk losing everything.
+If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything – the entire history of the project except whatever single snapshots people happen to have on their local machines.
+Local VCS systems suffer from this same problem – whenever you have the entire history of the project in a single place, you risk losing everything.
 
 ==== Distributed Version Control Systems (((version control,distributed version control)))
 
 This is where Distributed Version Control Systems (DVCSs) step in.
 In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don’t just check out the latest snapshot of the files: they fully mirror the repository.
 Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it.
-Every checkout is really a full backup of all the data (see <<dist_version_control>>).
+Every checkout is really a full backup of all the data.
 
-[[dist_version_control]]
 .Distributed version control.
 image::images/18333fig0103-tn.png[Distributed version control diagram]
 
@@ -69,9 +66,10 @@ This allows you to set up several types of workflows that aren’t possible in c
 === A Short History of Git
 
 As with many great things in life, Git began with a bit of creative destruction and fiery controversy.
+
 The Linux kernel is an open source software project of fairly large scope.
 For most of the lifetime of the Linux kernel maintenance (1991–2002), changes to the software were passed around as patches and archived files.
-In 2002, the Linux kernel project began using a proprietary DVCS system called BitKeeper.
+In 2002, the Linux kernel project began using a proprietary DVCS called BitKeeper.
 
 In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool’s free-of-charge status was revoked.
 This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper.
@@ -91,26 +89,24 @@ It’s incredibly fast, it’s very efficient with large projects, and it has an
 So, what is Git in a nutshell?
 This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you.
 As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool.
-Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar; understanding those differences will help prevent you from becoming confused while using it.
+Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar, and understanding those differences will help prevent you from becoming confused while using it.
 
 ==== Snapshots, Not Differences
 
 The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data.
 Conceptually, most other systems store information as a list of file-based changes.
-These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time, as illustrated in <<stream_of_deltas>>.
+These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time.
 
-[[stream_of_deltas]]
-.Other systems tend to store data as changes to a base version of each file.
-image::images/18333fig0104-tn.png[Other systems tend to store data as changes to a base version of each file.]
+.Storing data as changes to a base version of each file.
+image::images/18333fig0104-tn.png[Storing data as changes to a base version of each file.]
 
 Git doesn’t think of or store its data this way.
-Instead, Git thinks of its data more like a set of snapshots of a mini filesystem.
+Instead, Git thinks of its data more like a set of snapshots of a miniature filesystem.
 Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.
-To be efficient, if files have not changed, Git doesn’t store the file again–just a link to the previous identical file it has already stored.
-Git thinks about its data more like <<stream_of_snapshots>>.
+To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored.
+Git thinks about its data more like a *stream of snapshots*.
 
-[[stream_of_snapshots]]
-.Git stores data as snapshots of the project over time.
+.Storing data as snapshots of the project over time.
 image::images/18333fig0105-tn.png[Git stores data as snapshots of the project over time.]
 
 This is an important distinction between Git and nearly all other VCSs.
@@ -124,7 +120,7 @@ Most operations in Git only need local files and resources to operate – genera
 If you’re used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers.
 Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous.
 
-For example, to browse the history of the project, Git doesn’t need to go out to the server to get the history and display it for you–it simply reads it directly from your local database.
+For example, to browse the history of the project, Git doesn’t need to go out to the server to get the history and display it for you – it simply reads it directly from your local database.
 This means you see the project history almost instantly.
 If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally.
 
@@ -180,7 +176,7 @@ This is the most important part of Git, and it is what is copied when you clone
 The working directory is a single checkout of one version of the project.
 These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.
 
-The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit.
+The staging area is a file, generally contained in your Git directory, that stores information about what will go into your next commit.
 It’s sometimes referred to as the index, but it’s also common to refer to it as the staging area.
 
 The basic Git workflow goes something like this:
@@ -196,19 +192,19 @@ In <<_git_basics_chapter>>, you’ll learn more about these states and how you c
 
 === The Command Line
 
-There are a lot of different ways to use Git these days.
-There are the original command line tools and there are many graphical user interfaces as well of varying capabilities.
+There are a lot of different ways to use Git.
+There are the original command line tools, and there are many graphical user interfaces of varying capabilities.
 For this book, we will be using Git on the command line.
-For one, the command line is the only place you can run *all* Git commands - most of the GUIs only implement some subset of Git functionality for simplicity.
+For one, the command line is the only place you can run *all* Git commands – most of the GUIs only implement some subset of Git functionality for simplicity.
 If you know how to run the command line version, you can probably also figure out how to run the GUI version, while the opposite is not neccesarily true.
-Finally, while your choice of graphical client is a matter of personal taste, _all_ users will have the command-line tools installed and available.
+Also, while your choice of graphical client is a matter of personal taste, _all_ users will have the command-line tools installed and available.
 
-So, we will expect you to know how to open Terminal in Mac or Command Prompt or Powershell in Windows.
+So we will expect you to know how to open Terminal in Mac or Command Prompt or Powershell in Windows.
 If you don't know what we're talking about here, you may need to stop and research that quickly so that you can follow the rest of the examples and descriptions in this book.
 
 === Installing Git
 
-Let’s get into using some Git.
+Before you start using Git, you have to make it available on your computer.
 Even if it's already installed, it's probably a good idea to update to the latest version.
 You can either install it as a package or via another installer, or download the source code and compile it yourself.
 
@@ -223,9 +219,7 @@ Or if you’re on a Debian-based distribution like Ubuntu, try apt-get:
 
   $ apt-get install git
 
-For more options, there are instructions for installing on several different Unix flavors on the Git website:
-
-  http://git-scm.com/download/linux
+For more options, there are instructions for installing on several different Unix flavors on the Git website, at http://git-scm.com/download/linux[].
 
 ==== Installing on Mac
 
@@ -235,50 +229,44 @@ On Mavericks (10.9) or above you can do this simply by trying to run 'git' from
 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.
-An OSX Git installer is maintained and available for download here:
-
-  http://sourceforge.net/projects/git-osx-installer/
+An OSX Git installer is maintained and available for download at the Git website, at http://git-scm.com/download/mac[].
 
-[[git_osx_installer]]
 .Git OS X Installer.
-image::images/18333fig0107-tn.png[Git OS X installer.]
+image::images/git-osx-installer.png[Git OS X installer.]
 
 You can also install it as part of the GitHub for Mac 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.
-
-  http://mac.github.com/
+You can download that tool from the GitHub for Mac website, at http://mac.github.com[].
 
 ==== Installing on Windows
 
 There are also a few ways to install Git on Windows.
-You can go to the Git website to have it automatically download the current MsysGit installer.
-
-  http://git-scm.com/download/win
-
-If you want more information on the MsysGit project or build, you can also go directly to their homepage.
+The most official build is available for download on the Git website.
+Just go to http://git-scm.com/download/win[] and the download will start automatically.
+Note that this is a project called Git for Windows (also called msysGit), which is separate from Git itself; for more information on it, go to http://msysgit.github.io/[].
 
-  http://msysgit.github.io
 
-The GitHub for Windows installer will also install a command line version of Git as well as the GUI, so that is another easy option.
-It also works well with Powershell and sets up solid credential caching options and sane CRLF settings, so many people find it a simpler installation option.
-We'll learn more about both of those things a little later.
+Another easy way to get Git installed is by installing GitHub for Windows.
+The installer includes a command line version of Git as well as the GUI.
+It also works well with Powershell, and sets up solid credential caching and sane CRLF settings.
+We'll learn more about those things a little later, but suffice it to say they're things you want.
 
 === First-Time Git Setup
 
 Now that you have Git on your system, you’ll want to do a few things to customize your Git environment.
-You should have to do these things only once; they’ll stick around between upgrades.
+You should have to do these things only once on any given computer; they’ll stick around between upgrades.
 You can also change them at any time by running through the commands again.
 
 Git comes with a tool called `git config` that lets you get and set configuration variables that control all aspects of how Git looks and operates.
 These variables can be stored in three different places:
 
-* `/etc/gitconfig` file: Contains values for every user on the system and all their repositories.
+1. `/etc/gitconfig` file: Contains values for every user on the system and all their repositories.
   If you pass the option` --system` to `git config`, it reads and writes from this file specifically.
-* `~/.gitconfig` file: Specific to your user.
+2. `~/.gitconfig` or `~/.config/git/config` file: Specific to your user.
   You can make Git read and write to this file specifically by passing the `--global` option.
-* `config` file in the Git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository.
-  Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`.
+3. `config` file in the Git directory (that is, `.git/config`) of whatever repository you’re currently using: Specific to that single repository.
+
+Each level overrides values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`.
 
 On Windows systems, Git looks for the `.gitconfig` file in the `$HOME` directory (`C:\Users\$USER` for most people).
 It also still looks for `/etc/gitconfig`, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer.
@@ -298,22 +286,17 @@ For example, if you’re on a system that has yum (such as Fedora) or apt-get (s
     libz-dev libssl-dev
 
 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.
-
-  https://www.kernel.org/pub/software/scm/git
-
-Or the mirror on the GitHub web site.
-
-  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 web site, 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:
 
   $ tar -zxf git-1.9.1.tar.gz
   $ cd git-1.9.1
-  $ make prefix=/usr all doc info
-  $ sudo make prefix=/usr install install-doc install-html install-info
+  $ make configure
+  $ ./configure --prefix=/usr
+  $ make all doc info
+  $ sudo make install install-doc install-html install-info
 
 After this is done, you can also get Git via Git itself for updates:
 
@@ -335,7 +318,7 @@ Many of the GUI tools will help you do this when you first run them as well.
 ==== Your Editor
 
 Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message.
-By default, Git uses your system’s default editor, which is generally Vi or Vim.
+By default, Git uses your system’s default editor, which is generally vi or Vim.
 If you want to use a different text editor, such as Emacs, you can do the following:
 
   $ git config --global core.editor emacs
@@ -345,8 +328,8 @@ If you want to use a different text editor, such as Emacs, you can do the follow
 If you want to check your settings, you can use the `git config --list` command to list all the settings Git can find at that point:
 
   $ git config --list
-  user.name=Scott Chacon
-  user.email=schacon@gmail.com
+  user.name=John Doe
+  user.email=johndoe@example.com
   color.status=auto
   color.branch=auto
   color.interactive=auto
@@ -356,10 +339,10 @@ If you want to check your settings, you can use the `git config --list` command
 You may see keys more than once, because Git reads the same key from different files (`/etc/gitconfig` and `~/.gitconfig`, for example).
 In this case, Git uses the last value for each unique key it sees.
 
-You can also check what Git thinks a specific key’s value is by typing `git config {key}`:
+You can also check what Git thinks a specific key’s value is by typing `git config <key>`:
 
   $ git config user.name
-  Scott Chacon
+  John Doe
 
 === Getting Help