X-Git-Url: https://git.tokkee.org/?a=blobdiff_plain;f=Documentation%2Fuser-manual.txt;h=08d1310bf5fc5590ada1ee5b2af77d361ff4d874;hb=55e839e378416b70720308e86439e2ad6ecccc4a;hp=01c1af6b6a69253dd2460962fdfccb2d3bc50237;hpb=585ad90c804a501415f03926c1ef67a34cb37cda;p=git.git diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 01c1af6b6..08d1310bf 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -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 @@ -518,7 +517,7 @@ $ git bisect visualize ------------------------------------------------- which will run gitk and label the commit it chose with a marker that -says "bisect". Chose a safe-looking commit nearby, note its commit +says "bisect". Choose a safe-looking commit nearby, note its commit id, and check it out with: ------------------------------------------------- @@ -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 @@ -1988,8 +2003,8 @@ intend to manage the branch. It's also possible for a push to fail in this way when other people have the right to push to the same repository. In that case, the correct -solution is to retry the push after first updating your work by either a -pull or a fetch followed by a rebase; see the +solution is to retry the push after first updating your work: either by a +pull, or by a fetch followed by a rebase; see the <> and linkgit:gitcvs-migration[7] for more. @@ -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 ".dotest"), 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 @@ -2861,7 +2876,7 @@ There are four different types of objects: "blob", "tree", "commit", and "tag". - A <> is used to store file data. -- A <> is an object that ties one or more +- A <> ties one or more "blob" objects into a directory structure. In addition, a tree object can refer to other tree objects, thus creating a directory hierarchy. - A <> ties such directory hierarchies @@ -3036,7 +3051,7 @@ Tag Object A tag object contains an object, object type, tag name, the name of the person ("tagger") who created the tag, and a message, which may contain -a signature, as can be seen using the linkgit:git-cat-file[1]: +a signature, as can be seen using linkgit:git-cat-file[1]: ------------------------------------------------ $ git cat-file tag v1.5.0 @@ -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 ` 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 to the given 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 @@ -3986,13 +4001,13 @@ $ mv -f hello.c~2 hello.c $ git update-index hello.c ------------------------------------------------- -When a path is in unmerged state, running `git-update-index` for +When a path is in the "unmerged" state, running `git-update-index` for that path tells git to mark the path resolved. The above is the description of a git merge at the lowest level, to help you understand what conceptually happens under the hood. -In practice, nobody, not even git itself, uses three `git-cat-file` -for this. There is `git-merge-index` program that extracts the +In practice, nobody, not even git itself, runs `git-cat-file` three times +for this. There is a `git-merge-index` program that extracts the stages to temporary files and calls a "merge" script on it: ------------------------------------------------- @@ -4061,7 +4076,7 @@ Note that terminology has changed since that revision. For example, the README in that revision uses the word "changeset" to describe what we now call a <>. -Also, we do not call it "cache" any more, but "index", however, the +Also, we do not call it "cache" any more, but rather "index"; however, the file is still called `cache.h`. Remark: Not much reason to change it now, especially since there is no good single name for it anyway, because it is basically _the_ header file which is included by _all_ of Git's C sources.