X-Git-Url: https://git.cworth.org/git?a=blobdiff_plain;f=tour.mdwn;h=fdaa9a5577f2e07308f4cbca2c27080f80b4a3fe;hb=5a25922d84fe47eef6b9d6cd3c59e1d1aeed451e;hp=c511fab051c9e5d75d23316a5835dc749cfbcce9;hpb=5aef61cdf52d974653657dbeb41079555e4a868b;p=hgbook-git diff --git a/tour.mdwn b/tour.mdwn index c511fab..fdaa9a5 100644 --- a/tour.mdwn +++ b/tour.mdwn @@ -146,13 +146,18 @@ a directory tree in your filesystem that git treats as special. You can rename or delete a repository any time you like, using either the command line or your file browser. -#### 2.3.1 Making a local copy of a repository +#### 2.3.1 Creating a local copy of a remote repository -Copying a repository is just a little bit special. While you could use -a normal file copying command to make a copy of a repository, it’s -best to use a built-in command that git provides. This command -is called “git clone”, because it creates an identical copy of an -existing repository. +As suggested, a repository can be copied through normal file-copying +commands. But git also provides a "git clone" tool for copying a +repository. This provides a means of copying a repository over the +network, and is also useful with a local repository since it is much +more efficient than creating a normal copy, (creating a local clones +is blazingly fast). + +We've assembled a simple repository that will be used in the examples +throughout this chapter. Go ahead and clone this repository now so +that you will be able to follow along: $ git clone git://cworth.org/git/hello Initialized empty Git repository in /tmp/hello/.git/ @@ -339,7 +344,7 @@ in the current branch, "HEAD~", refers to the previous commit, and Another useful syntax is .. which can be used to specify a range of commits. So "origin..master" specifies everything that has been -committed to master since it derived from origin. +committed to master since it diverged from origin. #### 2.4.3 Viewing specific revisions @@ -371,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 @@ -719,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 " +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 " 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 “#”. @@ -1026,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 @@ -1055,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: