See also <<git-quick-start>> for a brief overview of git commands,
without any explanation.
-Also, see <<todo>> for ways that you can help make this manual more
+Finally, see <<todo>> for ways that you can help make this manual more
complete.
commits reachable from some head but not from any tag in the repository:
-------------------------------------------------
-$ gitk ($ git show-ref --heads ) --not $( git show-ref --tags )
+$ gitk $( git show-ref --heads ) --not $( git show-ref --tags )
-------------------------------------------------
(See gitlink:git-rev-parse[1] for explanations of commit-selecting
-------------------------------------------------
will use HEAD to produce a tar archive in which each filename is
-preceded by "prefix/".
+preceded by "project/".
If you're releasing a new version of a software project, you may want
to simultaneously make a changelog to include in the release
and then he just cut-and-pastes the output commands after verifying that
they look OK.
+[[Finding-comments-with-given-content]]
Finding commits referencing a file with given content
-----------------------------------------------------
Git therefore provides "exclude patterns" for telling git which files to
actively ignore. Exclude patterns are thoroughly explained in the
-"Exclude Patterns" section of the gitlink:git-ls-files[1] manual page,
-but the heart of the concept is simply a list of files which git should
-ignore. Entries in the list may contain globs to specify multiple files,
-or may be prefixed by "`!`" to explicitly include (un-ignore) a previously
-excluded (ignored) file (i.e. later exclude patterns override earlier ones).
-The following example should illustrate such patterns:
+gitlink:gitignore[5] manual page, but the heart of the concept is simply
+a list of files which git should ignore. Entries in the list may contain
+globs to specify multiple files, or may be prefixed by "`!`" to
+explicitly include (un-ignore) a previously excluded (ignored) file
+(i.e. later exclude patterns override earlier ones). The following
+example should illustrate such patterns:
-------------------------------------------------
# Lines starting with '#' are considered comments.
-------------------------------------------------
Dangling objects are not a problem. At worst they may take up a little
-extra disk space. They can sometimes provide a last-resort method of
-recovery lost work--see <<dangling-objects>> for details. However, if
-you want, you may remove them with gitlink:git-prune[1] or the --prune
+extra disk space. They can sometimes provide a last-resort method for
+recovering lost work--see <<dangling-objects>> for details. However, if
+you wish, you can remove them with gitlink:git-prune[1] or the --prune
option to gitlink:git-gc[1]:
-------------------------------------------------
that a branch is created:
-------------------------------------------------
-$ git checkout --track -b origin/maint maint
+$ git checkout --track -b maint origin/maint
-------------------------------------------------
In addition to saving you keystrokes, "git pull" also helps you by
If you and the maintainer both have accounts on the same machine, then
you can just pull changes from each other's repositories directly;
-commands that accepts repository URLs as arguments will also accept a
+commands that accept repository URLs as arguments will also accept a
local directory name:
-------------------------------------------------
$ git pull /path/to/other/repository
-------------------------------------------------
+or an ssh url:
+
+-------------------------------------------------
+$ git clone ssh://yourhost/~you/repository
+-------------------------------------------------
+
+For projects with few developers, or for synchronizing a few private
+repositories, this may be all you need.
+
However, the more common way to do this is to maintain a separate public
repository (usually on a different host) for others to pull changes
from. This is usually more convenient, and allows you to cleanly
| they push V
their public repo <------------------- their repo
+We explain how to do this in the following sections.
+
[[setting-up-a-public-repository]]
Setting up a public repository
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$ git push ssh://yourserver.com/~you/proj.git +master
-------------------------------------------------
+Note that the target of a "push" is normally a
+<<def_bare_repository,bare>> repository. You can also push to a
+repository that has a checked-out working tree, but the working tree
+will not be updated by the push. This may lead to unexpected results if
+the branch you push to is the currently checked-out branch!
+
As with git-fetch, you may also set up configuration options to
save typing; so, for example, after
independently of the contents or the type of the object: all objects can
be validated by verifying that (a) their hashes match the content of the
file and (b) the object successfully inflates to a stream of bytes that
-forms a sequence of <ascii type without space>
+ <space> + <ascii decimal
-size> + <byte\0> + <binary object data>.
+forms a sequence of <ascii type without space>
{plus} <space> {plus} <ascii decimal
+size> {plus} <byte\0> {plus} <binary object data>.
The structured objects can further have their structure and
connectivity to other objects verified. This is generally done with
include::glossary.txt[]
[[git-quick-start]]
-Appendix A: Git Quick Start
-===========================
+Appendix A: Git Quick Reference
+===============================
-This is a quick summary of the major commands; the following chapters
-will explain how these work in more detail.
+This is a quick summary of the major commands; the previous chapters
+explain how these work in more detail.
[[quick-creating-a-new-repository]]
Creating a new repository
More details on gitweb?
Write a chapter on using plumbing and writing scripts.
+
+Alternates, clone -reference, etc.
+
+git unpack-objects -r for recovery