Code

object name: introduce ':/<oneline prefix>' notation
[git.git] / Documentation / user-manual.txt
index 5f41a2d026e9dfa267aa278cf0d083dbe4132e72..03736bbcd3ebfd5e1cbe6a006acb2b31411af527 100644 (file)
@@ -398,7 +398,7 @@ branch name, but this longer name can also be useful.  Most
 importantly, it is a globally unique name for this commit: so if you
 tell somebody else the object name (for example in email), then you are
 guaranteed that name will refer to the same commit in their repository
-that you it does in yours (assuming their repository has that commit at
+that it does in yours (assuming their repository has that commit at
 all).
 
 Understanding history: commits, parents, and reachability
@@ -425,8 +425,8 @@ if commit X is an ancestor of commit Y.  Equivalently, you could say
 that Y is a descendent of X, or that there is a chain of parents
 leading from commit Y to commit X.
 
-Undestanding history: History diagrams
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Understanding history: History diagrams
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 We will sometimes represent git history using diagrams like the one
 below.  Commits are shown as "o", and the links between them with
@@ -617,7 +617,7 @@ the relationships between these snapshots.
 Git provides extremely flexible and fast tools for exploring the
 history of a project.
 
-We start with one specialized tool which is useful for finding the
+We start with one specialized tool that is useful for finding the
 commit that introduced a bug into a project.
 
 How to use bisect to find a regression
@@ -692,7 +692,7 @@ Naming commits
 
 We have seen several ways of naming commits already:
 
-       - 40-hexdigit SHA1 id
+       - 40-hexdigit object name
        - branch name: refers to the commit at the head of the given
          branch
        - tag name: refers to the commit pointed to by the given tag
@@ -705,7 +705,7 @@ gitlink:git-rev-parse[1] man page for the complete list of ways to
 name revisions.  Some examples:
 
 -------------------------------------------------
-$ git show fb47ddb2 # the first few characters of the SHA1 id
+$ git show fb47ddb2 # the first few characters of the object name
                    # are usually enough to specify it uniquely
 $ git show HEAD^    # the parent of the HEAD commit
 $ git show HEAD^^   # the grandparent
@@ -743,8 +743,8 @@ which refers to the other branch that we're merging in to the current
 branch.
 
 The gitlink:git-rev-parse[1] command is a low-level command that is
-occasionally useful for translating some name for a commit to the SHA1 id for
-that commit:
+occasionally useful for translating some name for a commit to the object
+name for that commit:
 
 -------------------------------------------------
 $ git rev-parse origin
@@ -806,7 +806,7 @@ display options.
 
 Note that git log starts with the most recent commit and works
 backwards through the parents; however, since git history can contain
-multiple independant lines of development, the particular order that
+multiple independent lines of development, the particular order that
 commits are listed in may be somewhat arbitrary.
 
 Generating diffs
@@ -861,7 +861,7 @@ $ git diff origin..master
 will tell you whether the contents of the project are the same at the
 two branches; in theory, however, it's possible that the same project
 contents could have been arrived at by two different historical
-routes.  You could compare the SHA1 id's:
+routes.  You could compare the object names:
 
 -------------------------------------------------
 $ git rev-list origin
@@ -1075,7 +1075,7 @@ $ git commit
 -------------------------------------------------
 
 and git will prompt you for a commit message and then create the new
-commmit.  Check to make sure it looks like what you expected with
+commit.  Check to make sure it looks like what you expected with
 
 -------------------------------------------------
 $ git show
@@ -1465,7 +1465,7 @@ $ gitk master@{"1 week ago"}      # ... or last week
 -------------------------------------------------
 
 The reflogs are kept by default for 30 days, after which they may be
-pruned.  See gitlink:git-reflink[1] and gitlink:git-gc[1] to learn
+pruned.  See gitlink:git-reflog[1] and gitlink:git-gc[1] to learn
 how to control this pruning, and see the "SPECIFYING REVISIONS"
 section of gitlink:git-rev-parse[1] for details.
 
@@ -1492,7 +1492,7 @@ dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5
 ...
 -------------------------------------------------
 
-and watch for output that mentions "dangling commits".  You can examine
+You can examine
 one of those dangling commits with, for example,
 
 ------------------------------------------------
@@ -1580,7 +1580,7 @@ Submitting patches to a project
 If you just have a few changes, the simplest way to submit them may
 just be to send them as patches in email:
 
-First, use gitlink:git-format-patches[1]; for example:
+First, use gitlink:git-format-patch[1]; for example:
 
 -------------------------------------------------
 $ git format-patch origin
@@ -1802,7 +1802,9 @@ set this up.
 Allow web browsing of a repository
 ----------------------------------
 
-TODO: Brief setup-instructions for gitweb
+The gitweb cgi script provides users an easy way to browse your
+project's files and history without having to install git; see the file
+gitweb/README in the git source tree for instructions on setting it up.
 
 Examples
 --------
@@ -2753,7 +2755,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
 ----------------------------------------------
@@ -2921,11 +2923,13 @@ Think about how to create a clear chapter dependency graph that will
 allow people to get to important topics without necessarily reading
 everything in between.
 
+Say something about .gitignore.
+
 Scan Documentation/ for other stuff left out; in particular:
        howto's
        some of technical/?
        hooks
-       etc.
+       list of commands in gitlink:git[1]
 
 Scan email archives for other stuff left out
 
@@ -2949,6 +2953,9 @@ Include cross-references to the glossary, where appropriate.
 Document shallow clones?  See draft 1.5.0 release notes for some
 documentation.
 
-Add a sectin on working with other version control systems, including
+Add a section on working with other version control systems, including
 CVS, Subversion, and just imports of series of release tarballs.
 
+More details on gitweb?
+
+Write a chapter on using plumbing and writing scripts.