Code

git-remote: list branches in vertical lists
[git.git] / Documentation / user-manual.txt
index 8761ee7e7d7ffe1202daff13c68a81dd2b19e18f..645d752c5c26d8724e8ded0abe1f207bf3ff6854 100644 (file)
@@ -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 latter 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
 --------------
@@ -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:
@@ -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
@@ -2431,7 +2446,7 @@ $ git rebase origin
 -------------------------------------------------
 
 This will remove each of your commits from mywork, temporarily saving
-them as patches (in a directory named ".git/rebase"), update mywork to
+them as patches (in a directory named ".git/rebase-apply"), update mywork to
 point at the latest version of origin, then apply each of the saved
 patches to the new mywork.  The result will look like:
 
@@ -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
@@ -3458,7 +3473,7 @@ $ cd super
 $ git init
 $ for i in a b c d
 do
-       git submodule add ~/git/$i
+       git submodule add ~/git/$i $i
 done
 -------------------------------------------------
 
@@ -3471,10 +3486,10 @@ $ ls -a
 .  ..  .git  .gitmodules  a  b  c  d
 -------------------------------------------------
 
-The `git-submodule add` command does a couple of things:
+The `git-submodule add <repo> <path>` command does a couple of things:
 
-- It clones the submodule under the current directory and by default checks out
-  the master branch.
+- It clones the submodule from <repo> to the given <path> under the
+  current directory and by default checks out the master branch.
 - It adds the submodule's clone path to the linkgit:gitmodules[5] file and
   adds this file to the index, ready to be committed.
 - It adds the submodule's current commit ID to the index, ready to be
@@ -4341,7 +4356,9 @@ $ git remote show example # get details
 * remote example
   URL: git://example.com/project.git
   Tracked remote branches
-    master next ...
+    master
+    next
+    ...
 $ git fetch example            # update branches from example
 $ git branch -r                        # list all remote branches
 -----------------------------------------------