]> git.cworth.org Git - hgbook-git/blobdiff - tour.mdwn
Fix typo: wihch -> which
[hgbook-git] / tour.mdwn
index e302d61775e31d7decf5101179386ad1f154b91c..fdaa9a5577f2e07308f4cbca2c27080f80b4a3fe 100644 (file)
--- a/tour.mdwn
+++ b/tour.mdwn
@@ -376,7 +376,7 @@ case):
 
 Besides filtering by commit identifiers, git allows you to easily
 filter the log output according to which files (or directories) are
-modified by listing them after "--" wihch is necessary to distinguish
+modified by listing them after "--" which is necessary to distinguish
 commit names from file names:
 
        $ git log -- Makefile
@@ -724,12 +724,18 @@ after we’ve finished committing.
 
        $ git commit -a
 
-Note: The -a on the command-line instructs git to commit all changes
-to tracked files. Without this, "git commit" will only commit changes
-that have been previously staged for committing with "git add
-file". The most common usage is to commit with "git commit -a" and
-only use "git add file; git commit" when there is a need to commit
-only some subset of changes that have been made.
+Note: The -a on the command-line instructs git to commit the new
+content of *all* tracked files that have been modified. This is a
+convenience over explicitly listing filenames to be committed on the
+"git commit" command line. It is useful to use "git commit <files>"
+when there is a need to commit only some subset of the files that have
+been modified.
+
+If new files need to be committed for the first time, just use "git
+add <file>" before "git commit -a". If a file needs to be removed,
+just remove it as normal before committing and "git commit -a" will
+notice that---it does not need to be explicitly told about the
+removal.
 
 The editor that the “git commit” command drops us into will contain an
 empty line, followed by a number of lines starting with “#”.
@@ -1031,21 +1037,21 @@ seems a little intimidating, understand that it's because things are
 not presented in the most natural "git way", (and I'm a little too
 tired to fix it tonight).]
 
-#### 2.8.2  Checking out previous revisions
+Note: Mercurial users who are reading this might wonder if there's a
+need for the equivalent of "hg update" after doing a "git pull". And
+the answer is no. Unlike mercurial, "git pull" and "git merge" will
+automatically update the workind-directory files as necessary.
 
-If any users of mercurial are reading this, they might wonder if
-there's a need for the equivalent of "hg update" after doing a "git
-pull". And the answer is no. Unlike mercurial, "git pull" and "git
-merge" will automatically update the workind-directory files as
-necessary.
+#### 2.8.2  Checking out previous revisions
 
-But there's another function provided by "hg update" which is to
-update the working-directory files to a particular revision. In git,
-this functionality is provided by the "git checkout" command. To
-checkout a particular branch, tag, or an arbitrary revions, simply
-give the appropriate name to the "git checkout" command. For example,
-to examine the files as they existed before the original typo
-introduction, we could do:
+It's often useful to examine the working-tree state of some specific
+revision other than the tip of some branch. For example, maybe you
+would like to build a particular tagged version, or maybe you'd like
+to test the behavior of the code before a particular change was
+introduced. To do this, use "git checkout" and pass it the name of any
+revision, (with a branch name, a tag name, or any other commit
+identifier). For example, to examine our project before the original
+typo was introduced:
 
        $ git checkout 0a633bf5
        Note: moving to "0a633bf5" which isn't a local branch
@@ -1060,6 +1066,10 @@ history, but if we actually wanted to use this revision as the basis
 for new commits, we would first have to create a new branch name as it
 describes.
 
+If we were to use "git checkout" with a branch name, then that would
+change the current branch, (meaning that any new commits would advance
+that branch pointer).
+
 For now, let's return back to the tip of the master branch by just
 checking it out again: