![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
index 01c1af6b6a69253dd2460962fdfccb2d3bc50237..08d1310bf5fc5590ada1ee5b2af77d361ff4d874 100644 (file)
-------------------------------------------------
If you run "git branch" at this point, you'll see that git has
-------------------------------------------------
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
-------------------------------------------------
$ git bisect bad
$ git bisect reset
-------------------------------------------------
$ 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
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
-------------------------------------------------
which will run gitk and label the commit it chose with a marker that
-------------------------------------------------
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:
-------------------------------------------------
id, and check it out with:
-------------------------------------------------
then test, run "bisect good" or "bisect bad" as appropriate, and
continue.
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
--------------
[[naming-commits]]
Naming commits
--------------
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
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:
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:
$ mv proj.git /home/you/public_html/proj.git
$ cd proj.git
$ git --bare update-server-info
$ 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
-------------------------------------------------
(For an explanation of the last two lines, see
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
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
<<setting-up-a-shared-repository,next section>> and
linkgit:gitcvs-migration[7] for more.
<<setting-up-a-shared-repository,next section>> and
linkgit:gitcvs-migration[7] for more.
-------------------------------------------------
This will remove each of your commits from mywork, temporarily saving
-------------------------------------------------
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:
point at the latest version of origin, then apply each of the saved
patches to the new mywork. The result will look like:
$ git config remote.example.fetch +master:ref/remotes/example/master
-------------------------------------------------
$ 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
Also note that all of the above configuration can be performed by
directly editing the file .git/config instead of using
"tag".
- A <<def_blob_object,"blob" object>> is used to store file data.
"tag".
- A <<def_blob_object,"blob" object>> is used to store file data.
-- A <<def_tree_object,"tree" object>> is an object that ties one or more
+- A <<def_tree_object,"tree" object>> 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 <<def_commit_object,"commit" object>> ties such directory hierarchies
"blob" objects into a directory structure. In addition, a tree object
can refer to other tree objects, thus creating a directory hierarchy.
- A <<def_commit_object,"commit" object>> ties such directory hierarchies
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 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
------------------------------------------------
$ git cat-file tag v1.5.0
$ git init
$ for i in a b c d
do
$ git init
$ for i in a b c d
do
- git submodule add ~/git/$i
+ git submodule add ~/git/$i $i
done
-------------------------------------------------
done
-------------------------------------------------
. .. .git .gitmodules a b c d
-------------------------------------------------
. .. .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
- 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
$ git update-index 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.
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:
-------------------------------------------------
stages to temporary files and calls a "merge" script on it:
-------------------------------------------------
README in that revision uses the word "changeset" to describe what we
now call a <<def_commit_object,commit>>.
README in that revision uses the word "changeset" to describe what we
now call a <<def_commit_object,commit>>.
-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.
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.