signature" letters (which optionally is terminated by another colon `:`),
and the remainder is the pattern to match against the path.
The "magic signature" consists of ASCII symbols that are neither
-alphanumeric, glob, regex special charaters nor colon.
+alphanumeric, glob, regex special characters nor colon.
The optional colon that terminates the "magic signature" can be
omitted if the pattern begins with a character that does not belong to
"magic signature" symbol set and is not a colon.
core Git. Porcelains expose more of a <<def_SCM,SCM>>
interface than the <<def_plumbing,plumbing>>.
+[[def_per_worktree_ref]]per-worktree ref::
+ Refs that are per-<<def_working_tree,worktree>>, rather than
+ global. This is presently only <<def_HEAD,HEAD>> and any refs
+ that start with `refs/bisect/`, but might later include other
+ unusual refs.
+
+[[def_pseudoref]]pseudoref::
+ Pseudorefs are a class of files under `$GIT_DIR` which behave
+ like refs for the purposes of rev-parse, but which are treated
+ specially by git. Pseudorefs both have names that are all-caps,
+ and always start with a line consisting of a
+ <<def_SHA1,SHA-1>> followed by whitespace. So, HEAD is not a
+ pseudoref, because it is sometimes a symbolic ref. They might
+ optionally contain some additional data. `MERGE_HEAD` and
+ `CHERRY_PICK_HEAD` are examples. Unlike
+ <<def_per_worktree_ref,per-worktree refs>>, these files cannot
+ be symbolic refs, and never have reflogs. They also cannot be
+ updated through the normal ref update machinery. Instead,
+ they are updated by directly writing to the files. However,
+ they can be read as if they were refs, so `git rev-parse
+ MERGE_HEAD` will work.
+
[[def_pull]]pull::
Pulling a <<def_branch,branch>> means to <<def_fetch,fetch>> it and
<<def_merge,merge>> it. See also linkgit:git-pull[1].
<<def_push,push>> to describe the mapping between remote
<<def_ref,ref>> and local ref.
+[[def_remote]]remote repository::
+ A <<def_repository,repository>> which is used to track the same
+ project but resides somewhere else. To communicate with remotes,
+ see <<def_fetch,fetch>> or <<def_push,push>>.
+
[[def_remote_tracking_branch]]remote-tracking branch::
A <<def_ref,ref>> that is used to follow changes from another
<<def_repository,repository>>. It typically looks like
"Secure Hash Algorithm 1"; a cryptographic hash function.
In the context of Git used as a synonym for <<def_object_name,object name>>.
+ [[def_shallow_clone]]shallow clone::
+ Mostly a synonym to <<def_shallow_repository,shallow repository>>
+ but the phrase makes it more explicit that it was created by
+ running `git clone --depth=...` command.
+
[[def_shallow_repository]]shallow repository::
A shallow <<def_repository,repository>> has an incomplete
history some of whose <<def_commit,commits>> have <<def_parent,parents>> cauterized away (in other
is created by giving the `--depth` option to linkgit:git-clone[1], and
its history can be later deepened with linkgit:git-fetch[1].
+[[def_submodule]]submodule::
+ A <<def_repository,repository>> that holds the history of a
+ separate project inside another repository (the latter of
+ which is called <<def_superproject, superproject>>).
+
+[[def_superproject]]superproject::
+ A <<def_repository,repository>> that references repositories
+ of other projects in its working tree as <<def_submodule,submodules>>.
+ The superproject knows about the names of (but does not hold
+ copies of) commit objects of the contained submodules.
+
[[def_symref]]symref::
Symbolic reference: instead of containing the <<def_SHA1,SHA-1>>
id itself, it is of the format 'ref: refs/some/thing' and when
If you wish the exclude patterns to affect only certain repositories
(instead of every repository for a given project), you may instead put
them in a file in your repository named `.git/info/exclude`, or in any
-file specified by the `core.excludesfile` configuration variable.
+file specified by the `core.excludesFile` configuration variable.
Some Git commands can also take exclude patterns directly on the
command line. See linkgit:gitignore[5] for the details.
parents, one pointing at each of the two lines of development that
were merged.
-However, if the current branch is a descendant of the other--so every
-commit present in the one is already contained in the other--then Git
-just performs a "fast-forward"; the head of the current branch is moved
-forward to point at the head of the merged-in branch, without any new
-commits being created.
+However, if the current branch is an ancestor of the other--so every commit
+present in the current branch is already contained in the other branch--then Git
+just performs a "fast-forward"; the head of the current branch is moved forward
+to point at the head of the merged-in branch, without any new commits being
+created.
[[fixing-mistakes]]
Fixing mistakes
[[fixing-a-mistake-by-rewriting-history]]
Fixing a mistake by rewriting history
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the problematic commit is the most recent commit, and you have not
yet made that commit public, then you may just
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The gitweb cgi script provides users an easy way to browse your
- project's files and history without having to install Git; see the file
- gitweb/INSTALL in the Git source tree for instructions on setting it up.
+ project's revisions, file contents and logs without having to install
+ Git. Features like RSS/Atom feeds and blame/annotation details may
+ optionally be enabled.
+
+ The linkgit:git-instaweb[1] command provides a simple way to start
+ browsing the repository using gitweb. The default server when using
+ instaweb is lighttpd.
+
+ See the file gitweb/INSTALL in the Git source tree and
+ linkgit:gitweb[1] for instructions on details setting up a permament
+ installation with a CGI or Perl capable server.
+
+ [[how-to-get-a-git-repository-with-minimal-history]]
+ How to get a Git repository with minimal history
+ ------------------------------------------------
+
+ A <<def_shallow_clone,shallow clone>>, with its truncated
+ history, is useful when one is interested only in recent history
+ of a project and getting full history from the upstream is
+ expensive.
+
+ A <<def_shallow_clone,shallow clone>> is created by specifying
+ the linkgit:git-clone[1] `--depth` switch. The depth can later be
+ changed with the linkgit:git-fetch[1] `--depth` switch, or full
+ history restored with `--unshallow`.
+
+ Merging inside a <<def_shallow_clone,shallow clone>> will work as long
+ as a merge base is in the recent history.
+ Otherwise, it will be like merging unrelated histories and may
+ have to result in huge conflicts. This limitation may make such
+ a repository unsuitable to be used in merge based workflows.
[[sharing-development-examples]]
Examples
[[the-index]]
The index
------------
+---------
The index is a binary file (generally kept in `.git/index`) containing a
sorted list of path names, each with permissions and the SHA-1 of a blob
controls how and what revisions are walked, and more.
The original job of `git rev-parse` is now taken by the function
-`setup_revisions()`, which parses the revisions and the common command line
+`setup_revisions()`, which parses the revisions and the common command-line
options for the revision walker. This information is stored in the struct
-`rev_info` for later consumption. You can do your own command line option
+`rev_info` for later consumption. You can do your own command-line option
parsing after calling `setup_revisions()`. After that, you have to call
`prepare_revision_walk()` for initialization, and then you can get the
commits one by one with the function `get_revision()`.
Scan man pages to see if any assume more background than this manual
provides.
- Simplify beginning by suggesting disconnected head instead of
- temporary branch creation?
-
Add more good examples. Entire sections of just cookbook examples
might be a good idea; maybe make an "advanced examples" section a
standard end-of-chapter section?
Include cross-references to the glossary, where appropriate.
- Document shallow clones? See draft 1.5.0 release notes for some
- documentation.
-
Add a section on working with other version control systems, including
CVS, Subversion, and just imports of series of release tarballs.
- More details on gitweb?
-
Write a chapter on using plumbing and writing scripts.
Alternates, clone -reference, etc.