diff.c: emit_add_line() takes only the rest of the line
[gitweb.git] / Documentation / user-manual.txt
index 00256ca57cc7453ef4a0dce90169078ee96e95e3..2ae88c575d0828809aafa242881d0377f7b54726 100644 (file)
@@ -13,7 +13,7 @@ to build and test a particular version of a software project, search for
 regressions, and so on.
 
 People needing to do actual development will also want to read
-<<Developing-with-git>> and <<sharing-development>>.
+<<Developing-With-git>> and <<sharing-development>>.
 
 Further chapters cover more specialized topics.
 
@@ -389,7 +389,7 @@ the order it uses to decide which to choose when there are multiple
 references with the same shorthand name, see the "SPECIFYING
 REVISIONS" section of linkgit:git-rev-parse[1].
 
-[[Updating-a-repository-with-git-fetch]]
+[[Updating-a-repository-With-git-fetch]]
 Updating a repository with git-fetch
 ------------------------------------
 
@@ -479,10 +479,10 @@ Bisecting: 3537 revisions left to test after this
 -------------------------------------------------
 
 If you run "git branch" at this point, you'll see that git has
-temporarily moved you to a new branch named "bisect".  This branch
-points to a commit (with commit id 65934...) that is reachable from
-"master" but not from v2.6.18.  Compile and test it, and see whether
-it crashes.  Assume it does crash.  Then:
+temporarily moved you in "(no branch)". HEAD is now detached from any
+branch and points directly to a commit (with commit id 65934...) that
+is reachable from "master" but not from v2.6.18. Compile and test it,
+and see whether it crashes. Assume it does crash. Then:
 
 -------------------------------------------------
 $ git bisect bad
@@ -504,8 +504,7 @@ report with the commit id.  Finally, run
 $ git bisect reset
 -------------------------------------------------
 
-to return you to the branch you were on before and delete the
-temporary "bisect" branch.
+to return you to the branch you were on before.
 
 Note that the version which git-bisect checks out for you at each
 point is just a suggestion, and you're free to try a different
@@ -528,6 +527,22 @@ $ git reset --hard fb47ddb2db...
 then test, run "bisect good" or "bisect bad" as appropriate, and
 continue.
 
+Instead of "git bisect visualize" and then "git reset --hard
+fb47ddb2db...", you might just want to tell git that you want to skip
+the current commit:
+
+-------------------------------------------------
+$ git bisect skip
+-------------------------------------------------
+
+In this case, though, git may not eventually be able to tell the first
+bad one between some first skipped commits and a later bad commit.
+
+There are also ways to automate the bisecting process if you have a
+test script that can tell a good from a bad commit. See
+linkgit:git-bisect[1] for more information about this and other "git
+bisect" features.
+
 [[naming-commits]]
 Naming commits
 --------------
@@ -930,7 +945,7 @@ echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new"
 and then he just cut-and-pastes the output commands after verifying that
 they look OK.
 
-[[Finding-comments-with-given-content]]
+[[Finding-comments-With-given-Content]]
 Finding commits referencing a file with given content
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -947,7 +962,7 @@ Figuring out why this works is left as an exercise to the (advanced)
 student.  The linkgit:git-log[1], linkgit:git-diff-tree[1], and
 linkgit:git-hash-object[1] man pages may prove helpful.
 
-[[Developing-with-git]]
+[[Developing-With-git]]
 Developing with git
 ===================
 
@@ -1113,8 +1128,8 @@ This typically includes files generated by a build process or temporary
 backup files made by your editor. Of course, 'not' tracking files with git
 is just a matter of 'not' calling "`git-add`" on them. But it quickly becomes
 annoying to have these untracked files lying around; e.g. they make
-"`git add .`" and "`git commit -a`" practically useless, and they keep
-showing up in the output of "`git status`".
+"`git add .`" practically useless, and they keep showing up in the output of
+"`git status`".
 
 You can tell git to ignore certain files by creating a file called .gitignore
 in the top level of your working directory, with contents such as:
@@ -1482,7 +1497,7 @@ so on a different branch and then coming back), unstash the
 work-in-progress changes.
 
 ------------------------------------------------
-$ git stash "work in progress for foo feature"
+$ git stash save "work in progress for foo feature"
 ------------------------------------------------
 
 This command will save your changes away to the `stash`, and
@@ -1650,7 +1665,7 @@ dangling objects can arise in other situations.
 Sharing development with others
 ===============================
 
-[[getting-updates-with-git-pull]]
+[[getting-updates-With-git-pull]]
 Getting updates with git-pull
 -----------------------------
 
@@ -1658,7 +1673,7 @@ After you clone a repository and make a few changes of your own, you
 may wish to check the original repository for updates and merge them
 into your own work.
 
-We have already seen <<Updating-a-repository-with-git-fetch,how to
+We have already seen <<Updating-a-repository-With-git-fetch,how to
 keep remote tracking branches up to date>> with linkgit:git-fetch[1],
 and how to merge two branches.  So you can merge in changes from the
 original repository's master branch with:
@@ -1769,7 +1784,7 @@ Public git repositories
 
 Another way to submit changes to a project is to tell the maintainer
 of that project to pull the changes from your repository using
-linkgit:git-pull[1].  In the section "<<getting-updates-with-git-pull,
+linkgit:git-pull[1].  In the section "<<getting-updates-With-git-pull,
 Getting updates with git-pull>>" we described this as a way to get
 updates from the "main" repository, but it works just as well in the
 other direction.
@@ -1875,7 +1890,7 @@ adjustments to give web clients some extra information they need:
 $ mv proj.git /home/you/public_html/proj.git
 $ cd proj.git
 $ git --bare update-server-info
-$ chmod a+x hooks/post-update
+$ mv hooks/post-update.sample hooks/post-update
 -------------------------------------------------
 
 (For an explanation of the last two lines, see
@@ -1979,7 +1994,7 @@ $ git push ssh://yourserver.com/~you/proj.git +master
 Normally whenever a branch head in a public repository is modified, it
 is modified to point to a descendant of the commit that it pointed to
 before.  By forcing a push in this situation, you break that convention.
-(See <<problems-with-rewriting-history>>.)
+(See <<problems-With-rewriting-history>>.)
 
 Nevertheless, this is a common practice for people that need a simple
 way to publish a work-in-progress patch series, and it is an acceptable
@@ -2548,7 +2563,7 @@ There are numerous other tools, such as StGIT, which exist for the
 purpose of maintaining a patch series.  These are outside of the scope of
 this manual.
 
-[[problems-with-rewriting-history]]
+[[problems-With-rewriting-history]]
 Problems with rewriting history
 -------------------------------
 
@@ -2810,8 +2825,8 @@ You can also add a "+" to force the update each time:
 $ git config remote.example.fetch +master:ref/remotes/example/master
 -------------------------------------------------
 
-Don't do this unless you're sure you won't mind "git-fetch" possibly
-throwing away commits on mybranch.
+Don't do this unless you're sure you won't mind "git fetch" possibly
+throwing away commits on 'example/master'.
 
 Also note that all of the above configuration can be performed by
 directly editing the file .git/config instead of using
@@ -4545,4 +4560,3 @@ Alternates, clone -reference, etc.
 More on recovery from repository corruption.  See:
        http://marc.theaimsgroup.com/?l=git&m=117263864820799&w=2
        http://marc.theaimsgroup.com/?l=git&m=117147855503798&w=2
-       http://marc.theaimsgroup.com/?l=git&m=117147855503798&w=2