prevent HEAD reflog to be interpreted as current branch reflog
[gitweb.git] / Documentation / user-manual.txt
index 8fd38e4efe02a92e4ec4fce4a903f844687aac71..b6916d11b228b3277eaa359573eedd9df0add6e8 100644 (file)
@@ -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
@@ -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
@@ -933,12 +933,38 @@ actually is an ancestor of v1.5.0-rc1.
 Alternatively, note that
 
 -------------------------------------------------
-$ git log v1.5.0-rc1..305db0fd
+$ git log v1.5.0-rc1..e05db0fd
 -------------------------------------------------
 
-will produce empty output if and only if v1.5.0-rc1 includes 305db0fd,
+will produce empty output if and only if v1.5.0-rc1 includes e05db0fd,
 because it outputs only commits that are not reachable from v1.5.0-rc1.
 
+As yet another alternative, the gitlink:git-show-branch[1] command lists
+the commits reachable from its arguments with a display on the left-hand
+side that indicates which arguments that commit is reachable from.  So,
+you can run something like
+
+-------------------------------------------------
+$ git show-branch e05db0fd v1.5.0-rc0 v1.5.0-rc1 v1.5.0-rc2
+! [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if
+available
+ ! [v1.5.0-rc0] GIT v1.5.0 preview
+  ! [v1.5.0-rc1] GIT v1.5.0-rc1
+   ! [v1.5.0-rc2] GIT v1.5.0-rc2
+...
+-------------------------------------------------
+
+then search for a line that looks like
+
+-------------------------------------------------
++ ++ [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if
+available
+-------------------------------------------------
+
+Which shows that e05db0fd is reachable from itself, from v1.5.0-rc1, and
+from v1.5.0-rc2, but not from v1.5.0-rc0.
+
+
 Developing with git
 ===================
 
@@ -1439,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.
 
@@ -1554,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
@@ -1776,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
 --------
@@ -1784,11 +1812,6 @@ Examples
 TODO: topic branches, typical roles as in everyday.txt, ?
 
 
-Working with other version control systems
-==========================================
-
-TODO: CVS, Subversion, series-of-release-tarballs, etc.
-
 [[cleaning-up-history]]
 Rewriting history and maintaining patch series
 ==============================================
@@ -2902,10 +2925,9 @@ everything in between.
 
 Scan Documentation/ for other stuff left out; in particular:
        howto's
-       README
        some of technical/?
        hooks
-       etc.
+       list of commands in gitlink:git[1]
 
 Scan email archives for other stuff left out
 
@@ -2926,6 +2948,12 @@ standard end-of-chapter section?
 
 Include cross-references to the glossary, where appropriate.
 
-To document:
-       reflogs, git reflog expire
-       shallow clones??  See draft 1.5.0 release notes for some documentation.
+Document shallow clones?  See draft 1.5.0 release notes for some
+documentation.
+
+Add a sectin 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.