Code

Merge branch 'maint'
[git.git] / Documentation / gitcore-tutorial.txt
index 49179b0a00fad1ecda1fdf0537ccbce77f5fc494..7ba5e589d7e824c526482c9707a5c26ac730cc9e 100644 (file)
@@ -899,7 +899,7 @@ file, which had no differences in the `mybranch` branch), and say:
 ----------------
        Auto-merging hello
        CONFLICT (content): Merge conflict in hello
 ----------------
        Auto-merging hello
        CONFLICT (content): Merge conflict in hello
-       Automatic merge failed; fix up by hand
+       Automatic merge failed; fix conflicts and then commit the result.
 ----------------
 
 It tells you that it did an "Automatic merge", which
 ----------------
 
 It tells you that it did an "Automatic merge", which
@@ -993,14 +993,14 @@ would be different)
 
 ----------------
 Updating from ae3a2da... to a80b4aa....
 
 ----------------
 Updating from ae3a2da... to a80b4aa....
-Fast forward
+Fast forward (no commit created; -m option ignored)
  example |    1 +
  hello   |    1 +
  2 files changed, 2 insertions(+), 0 deletions(-)
 ----------------
 
  example |    1 +
  hello   |    1 +
  2 files changed, 2 insertions(+), 0 deletions(-)
 ----------------
 
-Because your branch did not contain anything more than what are
-already merged into the `master` branch, the merge operation did
+Because your branch did not contain anything more than what had
+already been merged into the `master` branch, the merge operation did
 not actually do a merge. Instead, it just updated the top of
 the tree of your branch to that of the `master` branch. This is
 often called 'fast forward' merge.
 not actually do a merge. Instead, it just updated the top of
 the tree of your branch to that of the `master` branch. This is
 often called 'fast forward' merge.
@@ -1243,10 +1243,10 @@ $ git ls-files --stage
 ------------
 
 In our example of only two files, we did not have unchanged
 ------------
 
 In our example of only two files, we did not have unchanged
-files so only 'example' resulted in collapsing, but in real-life
-large projects, only small number of files change in one commit,
-and this 'collapsing' tends to trivially merge most of the paths
-fairly quickly, leaving only a handful the real changes in non-zero
+files so only 'example' resulted in collapsing.  But in real-life
+large projects, when only a small number of files change in one commit,
+this 'collapsing' tends to trivially merge most of the paths
+fairly quickly, leaving only a handful of real changes in non-zero
 stages.
 
 To look at only non-zero stages, use `\--unmerged` flag:
 stages.
 
 To look at only non-zero stages, use `\--unmerged` flag:
@@ -1265,9 +1265,8 @@ file, using 3-way merge.  This is done by giving
 
 ------------
 $ git merge-index git-merge-one-file hello
 
 ------------
 $ git merge-index git-merge-one-file hello
-Auto-merging hello.
-merge: warning: conflicts during merge
-ERROR: Merge conflict in hello.
+Auto-merging hello
+ERROR: Merge conflict in hello
 fatal: merge program failed
 ------------
 
 fatal: merge program failed
 ------------
 
@@ -1353,7 +1352,7 @@ $ GIT_DIR=my-git.git git init
 ------------
 
 Make sure this directory is available for others you want your
 ------------
 
 Make sure this directory is available for others you want your
-changes to be pulled by via the transport of your choice. Also
+changes to be pulled via the transport of your choice. Also
 you need to make sure that you have the 'git-receive-pack'
 program on the `$PATH`.
 
 you need to make sure that you have the 'git-receive-pack'
 program on the `$PATH`.
 
@@ -1366,8 +1365,9 @@ your login shell is 'bash', only `.bashrc` is read and not
 
 [NOTE]
 If you plan to publish this repository to be accessed over http,
 
 [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.
 repository, `git update-server-info` is run.
 
 Your "public repository" is now ready to accept your changes.
@@ -1446,7 +1446,7 @@ public repository you might want to repack & prune often, or
 never.
 
 If you run `git repack` again at this point, it will say
 never.
 
 If you run `git repack` again at this point, it will say
-"Nothing to pack". Once you continue your development and
+"Nothing new to pack.". Once you continue your development and
 accumulate the changes, running `git repack` again will create a
 new pack, that contains objects created since you packed your
 repository the last time. We recommend that you pack your project
 accumulate the changes, running `git repack` again will create a
 new pack, that contains objects created since you packed your
 repository the last time. We recommend that you pack your project
@@ -1486,11 +1486,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`,
 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.
 
 3. Push into the public repository from your primary
    repository.
@@ -1511,7 +1511,7 @@ You can repack this private repository whenever you feel like.
 6. Push your changes to the public repository, and announce it
    to the public.
 
 6. Push your changes to the public repository, and announce it
    to the public.
 
-7. Every once in a while, "git-repack" the public repository.
+7. Every once in a while, 'git-repack' the public repository.
    Go back to step 5. and continue working.
 
 
    Go back to step 5. and continue working.
 
 
@@ -1689,8 +1689,11 @@ to follow, not easier.
 
 SEE ALSO
 --------
 
 SEE ALSO
 --------
-linkgit:gittutorial[7], linkgit:gittutorial-2[7],
-linkgit:everyday[7], linkgit:gitcvs-migration[7],
+linkgit:gittutorial[7],
+linkgit:gittutorial-2[7],
+linkgit:gitcvs-migration[7],
+linkgit:git-help[1],
+link:everyday.html[Everyday git],
 link:user-manual.html[The Git User's Manual]
 
 GIT
 link:user-manual.html[The Git User's Manual]
 
 GIT