Merge git://git2.kernel.org/pub/scm/gitk/gitk

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index f4ea967191686f749796d94de28db59db10d0ade..d7b227e6471f6571129477c57a25d383f6b8c008 100644 (file)
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -437,11 +437,14 @@ We will sometimes represent git history using diagrams like the one
 below.  Commits are shown as "o", and the links between them with
 lines drawn with - / and \.  Time goes left to right:
 
+
+................................................
          o--o--o <-- Branch A
         /
  o--o--o <-- master
         \
          o--o--o <-- Branch B
+................................................
 
 If we need to talk about a particular commit, the character "o" may
 be replaced with another letter or number.
@@ -1431,7 +1434,7 @@ modifying the working directory, you can do that with
 gitlink:git-show[1]:
 
 -------------------------------------------------
-$ git show HEAD^ path/to/file
+$ git show HEAD^:path/to/file
 -------------------------------------------------
 
 which will display the given version of the file.
@@ -1928,25 +1931,29 @@ $ git commit
 You have performed no merges into mywork, so it is just a simple linear
 sequence of patches on top of "origin":
 
-
+................................................
  o--o--o <-- origin
         \
          o--o--o <-- mywork
+................................................
 
 Some more interesting work has been done in the upstream project, and
 "origin" has advanced:
 
+................................................
  o--o--O--o--o--o <-- origin
         \
          a--b--c <-- mywork
+................................................
 
 At this point, you could use "pull" to merge your changes back in;
 the result would create a new merge commit, like this:
 
-
+................................................
  o--o--O--o--o--o <-- origin
         \        \
          a--b--c--m <-- mywork
+................................................
  
 However, if you prefer to keep the history in mywork a simple series of
 commits without any merges, you may instead choose to use
@@ -1963,9 +1970,11 @@ point at the latest version of origin, then apply each of the saved
 patches to the new mywork.  The result will look like:
 
 
+................................................
  o--o--O--o--o--o <-- origin
                 \
                  a'--b'--c' <-- mywork
+................................................
 
 In the process, it may discover conflicts.  In that case it will stop
 and allow you to fix the conflicts; after fixing conflicts, use "git
@@ -2073,24 +2082,30 @@ The primary problem with rewriting the history of a branch has to do
 with merging.  Suppose somebody fetches your branch and merges it into
 their branch, with a result something like this:
 
+................................................
  o--o--O--o--o--o <-- origin
         \        \
          t--t--t--m <-- their branch:
+................................................
 
 Then suppose you modify the last three commits:
 
+................................................
         o--o--o <-- new head of origin
        /
  o--o--O--o--o--o <-- old head of origin
+................................................
 
 If we examined all this history together in one repository, it will
 look like:
 
+................................................
         o--o--o <-- new head of origin
        /
  o--o--O--o--o--o <-- old head of origin
         \        \
          t--t--t--m <-- their branch:
+................................................
 
 Git has no way of knowing that the new head is an updated version of
 the old head; it treats this situation exactly the same as it would if
@@ -2151,9 +2166,11 @@ commit.  Git calls this process a "fast forward".
 
 A fast forward looks something like this:
 
+................................................
  o--o--o--o <-- old head of the branch
            \
             o--o--o <-- new head of the branch
+................................................
 
 
 In some cases it is possible that the new head will *not* actually be
@@ -2161,11 +2178,11 @@ a descendant of the old head.  For example, the developer may have
 realized she made a serious mistake, and decided to backtrack,
 resulting in a situation like:
 
+................................................
  o--o--o--o--a--b <-- old head of the branch
            \
             o--o--o <-- new head of the branch
-
-
+................................................
 
 In this case, "git fetch" will fail, and print out a warning.
 
@@ -2853,7 +2870,7 @@ stages to temporary files and calls a "merge" script on it:
 $ git-merge-index git-merge-one-file hello.c
 -------------------------------------------------
 
-and that is what higher level `git resolve` is implemented with.
+and that is what higher level `git merge -s resolve` is implemented with.
 
 How git stores objects efficiently: pack files
 ----------------------------------------------