Code

Add help.autocorrect to enable/disable autocorrecting
[git.git] / Documentation / gitcore-tutorial.txt
index 3eba973a2bfc142df70617ff8456908082c3fb06..a417e592ac6a7ed72186dcfc241592ccdc25c9d2 100644 (file)
@@ -61,7 +61,7 @@ Initialized empty Git repository in .git/
 which is just git's way of saying that you haven't been doing anything
 strange, and that it will have created a local `.git` directory setup for
 your new project. You will now have a `.git` directory, and you can
-inspect that with `ls`. For your new empty project, it should show you
+inspect that with 'ls'. For your new empty project, it should show you
 three entries, among other things:
 
  - a file called `HEAD`, that has `ref: refs/heads/master` in it.
@@ -235,7 +235,7 @@ $ git diff-files
 ------------
 
 Oops. That wasn't very readable. It just spit out its own internal
-version of a `diff`, but that internal version really just tells you
+version of a 'diff', but that internal version really just tells you
 that it has noticed that "hello" has been modified, and that the old object
 contents it had have been replaced with something else.
 
@@ -468,7 +468,7 @@ Inspecting Changes
 
 While creating changes is useful, it's even more useful if you can tell
 later what changed. The most useful command for this is another of the
-`diff` family, namely 'git-diff-tree'.
+'diff' family, namely 'git-diff-tree'.
 
 'git-diff-tree' can be given two arbitrary trees, and it will tell you the
 differences between them. Perhaps even more commonly, though, you can
@@ -660,7 +660,7 @@ in the new repository to make sure that the index file is up-to-date.
 
 Note that the second point is true even across machines. You can
 duplicate a remote git repository with *any* regular copy mechanism, be it
-`scp`, `rsync` or `wget`.
+'scp', 'rsync' or 'wget'.
 
 When copying a remote repository, you'll want to at a minimum update the
 index cache when you do this, and especially with other peoples'
@@ -1006,7 +1006,7 @@ the tree of your branch to that of the `master` branch. This is
 often called 'fast forward' merge.
 
 You can run `gitk \--all` again to see how the commit ancestry
-looks like, or run `show-branch`, which tells you this.
+looks like, or run 'show-branch', which tells you this.
 
 ------------------------------------------------
 $ git show-branch master mybranch
@@ -1066,9 +1066,9 @@ most efficient way to exchange git objects between repositories.
 Local directory::
        `/path/to/repo.git/`
 +
-This transport is the same as SSH transport but uses `sh` to run
+This transport is the same as SSH transport but uses 'sh' to run
 both ends on the local machine instead of running other end on
-the remote machine via `ssh`.
+the remote machine via 'ssh'.
 
 git Native::
        `git://remote.machine/path/to/repo.git/`
@@ -1275,8 +1275,8 @@ fatal: merge program failed
 describe those three versions, and is responsible to leave the
 merge results in the working tree.
 It is a fairly straightforward shell script, and
-eventually calls `merge` program from RCS suite to perform a
-file-level 3-way merge.  In this case, `merge` detects
+eventually calls 'merge' program from RCS suite to perform a
+file-level 3-way merge.  In this case, 'merge' detects
 conflicts, and the merge result with conflict marks is left in
 the working tree..  This can be seen if you run `ls-files
 --stage` again at this point:
@@ -1360,14 +1360,15 @@ program on the `$PATH`.
 [NOTE]
 Many installations of sshd do not invoke your shell as the login
 shell when you directly run programs; what this means is that if
-your login shell is `bash`, only `.bashrc` is read and not
+your login shell is 'bash', only `.bashrc` is read and not
 `.bash_profile`. As a workaround, make sure `.bashrc` sets up
 `$PATH` so that you can run 'git-receive-pack' program.
 
 [NOTE]
 If you plan to publish this repository to be accessed over http,
-you should do `chmod +x my-git.git/hooks/post-update` at this
-point.  This makes sure that every time you push into this
+you should do `mv my-git.git/hooks/post-update.sample
+my-git.git/hooks/post-update` at this point.
+This makes sure that every time you push into this
 repository, `git update-server-info` is run.
 
 Your "public repository" is now ready to accept your changes.
@@ -1486,11 +1487,11 @@ A recommended workflow for a "project lead" goes like this:
 If other people are pulling from your repository over dumb
 transport protocols (HTTP), you need to keep this repository
 'dumb transport friendly'.  After `git init`,
-`$GIT_DIR/hooks/post-update` copied from the standard templates
-would contain a call to 'git-update-server-info' but the
-`post-update` hook itself is disabled by default -- enable it
-with `chmod +x post-update`.  This makes sure 'git-update-server-info'
-keeps the necessary files up-to-date.
+`$GIT_DIR/hooks/post-update.sample` copied from the standard templates
+would contain a call to 'git-update-server-info'
+but you need to manually enable the hook with
+`mv post-update.sample post-update`.  This makes sure
+'git-update-server-info' keeps the necessary files up-to-date.
 
 3. Push into the public repository from your primary
    repository.
@@ -1655,7 +1656,7 @@ branch before these two merges by resetting it to 'master~2':
 $ git reset --hard master~2
 ------------
 
-You can make sure 'git show-branch' matches the state before
+You can make sure `git show-branch` matches the state before
 those two 'git-merge' you just did.  Then, instead of running
 two 'git-merge' commands in a row, you would merge these two
 branch heads (this is known as 'making an Octopus'):
@@ -1690,7 +1691,7 @@ to follow, not easier.
 SEE ALSO
 --------
 linkgit:gittutorial[7], linkgit:gittutorial-2[7],
-linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
+linkgit:everyday[7], linkgit:gitcvs-migration[7],
 link:user-manual.html[The Git User's Manual]
 
 GIT