X-Git-Url: https://git.cworth.org/git?a=blobdiff_plain;f=tour.mdwn;h=fdaa9a5577f2e07308f4cbca2c27080f80b4a3fe;hb=5a25922d84fe47eef6b9d6cd3c59e1d1aeed451e;hp=47582b241080d437b83be3cdff1d94484bde2bb7;hpb=34031ee28700d2645ea0722d466d7c0874a4af71;p=hgbook-git diff --git a/tour.mdwn b/tour.mdwn index 47582b2..fdaa9a5 100644 --- a/tour.mdwn +++ b/tour.mdwn @@ -32,12 +32,12 @@ Changes made by Carl include the following: The source of this modified version can be obtained via git: git clone git://cworth.org/git/hgbook-git + or - git clone http://cworth.org/git/hgbook-git -and can be browsed online: + git clone http://cworth.org/git/hgbook-git - http://git.cworth.org/git/hgbook-git +and can be [browsed online](http://git.cworth.org/git/hgbook-git) ### 2.1 Installing git on your system @@ -78,7 +78,7 @@ with git, meaning GNU Interactive Tools). * Ubuntu - apt-get install git + apt-get install git-core #### 2.1.2 Mac OS X @@ -100,7 +100,7 @@ installers. These include GitMe, a package to install the entire development environment necessary to work on improving the msysgit port of git, and WinGit, a package for installing just git itself without the development environment, (still in Alpha as of September -2008). +2007). ### 2.2 Getting started @@ -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 + +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). -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. +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 @@ -395,7 +400,7 @@ created: Another useful option is -n or --max-count which, unsurprisingly, limits the maximum number of commits to be displayed. -#### 2.4.3 More detailed information +#### 2.4.5 More detailed information While the default information printed by “git log” is useful if you already know what you’re looking for, you may need to see more details @@ -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: