--- /dev/null
+GIT v1.5.3.5 Release Notes
+==========================
+
+Fixes since v1.5.3.4
+--------------------
+
+ * Comes with git-gui 0.8.4.
+
+ * "git-config" silently ignored options after --list; now it will
+ error out with a usage message.
+
+ * "git-config --file" failed if the argument used a relative path
+ as it changed directories before opening the file.
+
+ * "git-config --file" now displays a proper error message if it
+ cannot read the file specified on the command line.
+
+ * "git-config", "git-diff", "git-apply" failed if run from a
+ subdirectory with relative GIT_DIR and GIT_WORK_TREE set.
+
+ * "git-blame" crashed if run during a merge conflict.
+
+ * "git-add -i" did not handle single line hunks correctly.
+
+ * "git-rebase -i" and "git-stash apply" failed if external diff
+ drivers were used for one or more files in a commit. They now
+ avoid calling the external diff drivers.
+
+ * "git-log --follow" did not work unless diff generation (e.g. -p)
+ was also requested.
+
+ * "git-log --follow -B" did not work at all. Fixed.
+
+ * "git-log -M -B" did not correctly handle cases of very large files
+ being renamed and replaced by very small files in the same commit.
+
+ * "git-log" printed extra newlines between commits when a diff
+ was generated internally (e.g. -S or --follow) but not displayed.
+
+ * "git-push" error message is more helpful when pushing to a
+ repository with no matching refs and none specified.
+
+ * "git-push" now respects + (force push) on wildcard refspecs,
+ matching the behavior of git-fetch.
+
+ * "git-filter-branch" now updates the working directory when it
+ has finished filtering the current branch.
+
+ * "git-instaweb" no longer fails on Mac OS X.
+
+ * "git-cvsexportcommit" didn't always create new parent directories
+ before trying to create new child directories. Fixed.
+
+ * "git-fetch" printed a scary (but bogus) error message while
+ fetching a tag that pointed to a tree or blob. The error did
+ not impact correctness, only user perception. The bogus error
+ is no longer printed.
+
+ * "git-ls-files --ignored" did not properly descend into non-ignored
+ directories that themselves contained ignored files if d_type
+ was not supported by the filesystem. This bug impacted systems
+ such as AFS. Fixed.
+
+ * Git segfaulted when reading an invalid .gitattributes file. Fixed.
+
+ * post-receive-email example hook fixed was fixed for
+ non-fast-forward updates.
+
+ * Documentation updates for supported (but previously undocumented)
+ options of "git-archive" and "git-reflog".
+
+ * "make clean" no longer deletes the configure script that ships
+ with the git tarball, making multiple architecture builds easier.
Set the path to the working tree. The value will not be
used in combination with repositories found automatically in
a .git directory (i.e. $GIT_DIR is not set).
- This can be overriden by the GIT_WORK_TREE environment
+ This can be overridden by the GIT_WORK_TREE environment
variable and the '--work-tree' command line option.
core.logAllRefUpdates::
message if conflicts were detected. Level 1 outputs only
conflicts, 2 outputs conflicts and file changes. Level 5 and
above outputs debugging information. The default is level 2.
- Can be overriden by 'GIT_MERGE_VERBOSITY' environment variable.
+ Can be overridden by 'GIT_MERGE_VERBOSITY' environment variable.
merge.<driver>.name::
Defines a human readable name for a custom low-level
<div class="sectionbody">\r
<div class="verseblock">\r
<div class="content"><em>git-archive</em> --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]\r
- [--remote=<repo>] <tree-ish> [path…]</div></div>\r
+ [--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>\r
+ [path…]</div></div>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
</p>\r
</dd>\r
<dt>\r
+--exec=<git-upload-archive>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Used with --remote to specify the path to the\r
+ git-upload-archive executable on the remote side.\r
+</p>\r
+</dd>\r
+<dt>\r
<tree-ish>\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 15-Sep-2007 07:45:31 UTC\r
+Last updated 23-Oct-2007 01:21:45 UTC\r
</div>\r
</div>\r
</body>\r
--------
[verse]
'git-archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
- [--remote=<repo>] <tree-ish> [path...]
+ [--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
+ [path...]
DESCRIPTION
-----------
Instead of making a tar archive from local repository,
retrieve a tar archive from a remote repository.
+--exec=<git-upload-archive>::
+ Used with --remote to specify the path to the
+ git-upload-archive executable on the remote side.
+
<tree-ish>::
The tree or commit to produce an archive for.
</dt>\r
<dd>\r
<p>\r
- Cause the command to append which commit was\r
- cherry-picked after the original commit message when\r
- making a commit. Do not use this option if you are\r
- cherry-picking from your private branch because the\r
- information is useless to the recipient. If on the\r
+ When recording the commit, append to the original commit\r
+ message a note that indicates which commit this change\r
+ was cherry-picked from. Append the note only for cherry\r
+ picks without conflicts. Do not use this option if\r
+ you are cherry-picking from your private branch because\r
+ the information is useless to the recipient. If on the\r
other hand you are cherry-picking between two publicly\r
visible branches (e.g. backporting a fix to a\r
maintenance branch for an older release from a\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:09:33 UTC\r
+Last updated 23-Oct-2007 01:21:45 UTC\r
</div>\r
</div>\r
</body>\r
message prior committing.
-x::
- Cause the command to append which commit was
- cherry-picked after the original commit message when
- making a commit. Do not use this option if you are
- cherry-picking from your private branch because the
- information is useless to the recipient. If on the
+ When recording the commit, append to the original commit
+ message a note that indicates which commit this change
+ was cherry-picked from. Append the note only for cherry
+ picks without conflicts. Do not use this option if
+ you are cherry-picking from your private branch because
+ the information is useless to the recipient. If on the
other hand you are cherry-picking between two publicly
visible branches (e.g. backporting a fix to a
maintenance branch for an older release from a
Set the path to the working tree. The value will not be\r
used in combination with repositories found automatically in\r
a .git directory (i.e. $GIT_DIR is not set).\r
- This can be overriden by the GIT_WORK_TREE environment\r
+ This can be overridden by the GIT_WORK_TREE environment\r
variable and the <em>--work-tree</em> command line option.\r
</p>\r
</dd>\r
message if conflicts were detected. Level 1 outputs only\r
conflicts, 2 outputs conflicts and file changes. Level 5 and\r
above outputs debugging information. The default is level 2.\r
- Can be overriden by <em>GIT_MERGE_VERBOSITY</em> environment variable.\r
+ Can be overridden by <em>GIT_MERGE_VERBOSITY</em> environment variable.\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Oct-2007 12:03:44 UTC\r
+Last updated 23-Oct-2007 01:21:46 UTC\r
</div>\r
</div>\r
</body>\r
</li>\r
<li>\r
<p>\r
-Changes that occured on the master branch since when the topic\r
+Changes that occurred on the master branch since when the topic\r
branch was started off it.\r
</p>\r
</li>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Oct-2007 12:03:48 UTC\r
+Last updated 23-Oct-2007 01:21:46 UTC\r
</div>\r
</div>\r
</body>\r
+
<1> Changes between the tips of the topic and the master branches.
<2> Same as above.
-<3> Changes that occured on the master branch since when the topic
+<3> Changes that occurred on the master branch since when the topic
branch was started off it.
Limiting the diff output::
<div class="content">\r
<pre><tt>git filter-branch --index-filter 'git update-index --remove filename' HEAD</tt></pre>\r
</div></div>\r
-<p>Now, you will get the rewritten history saved in the branch <em>newbranch</em>\r
-(your current branch is left untouched).</p>\r
+<p>Now, you will get the rewritten history saved in HEAD.</p>\r
<p>To set a commit (which typically is at the tip of another\r
history) to be the parent of the current initial commit, in\r
order to paste the other history behind the current history:</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 14-Sep-2007 10:06:09 UTC\r
+Last updated 23-Oct-2007 01:21:48 UTC\r
</div>\r
</div>\r
</body>\r
git filter-branch --index-filter 'git update-index --remove filename' HEAD
--------------------------------------------------------------------------
-Now, you will get the rewritten history saved in the branch 'newbranch'
-(your current branch is left untouched).
+Now, you will get the rewritten history saved in HEAD.
To set a commit (which typically is at the tip of another
history) to be the parent of the current initial commit, in
created from prior invocations of <a href="git-add.html">git-add(1)</a>.</p>\r
<p>Users are encouraged to run this task on a regular basis within\r
each repository to maintain good disk space utilization and good\r
-operating performance.</p>\r
+operating performance. Some git commands may automatically run\r
+<tt>git-gc</tt>; see the <tt>--auto</tt> flag below for details.</p>\r
</div>\r
<h2>OPTIONS</h2>\r
<div class="sectionbody">\r
</dt>\r
<dd>\r
<p>\r
- With this option, <tt>git gc</tt> checks if there are too many\r
- loose objects in the repository and runs\r
- <a href="git-repack.html">git-repack(1)</a> with <tt>-d -l</tt> option to pack them.\r
- The threshold for loose objects is set with <tt>gc.auto</tt> configuration\r
- variable, and can be disabled by setting it to 0. Some\r
- Porcelain commands use this after they perform operation\r
- that could create many loose objects automatically.\r
- Additionally, when there are too many packs are present,\r
- they are consolidated into one larger pack by running\r
- the <tt>git-repack</tt> command with <tt>-A</tt> option. The\r
- threshold for number of packs is set with\r
- <tt>gc.autopacklimit</tt> configuration variable.\r
+ With this option, <tt>git gc</tt> checks whether any housekeeping is\r
+ required; if not, it exits without performing any work.\r
+ Some git commands run <tt>git gc --auto</tt> after performing\r
+ operations that could create many loose objects.\r
</p>\r
+<p>Housekeeping is required if there are too many loose objects or\r
+too many packs in the repository. If the number of loose objects\r
+exceeds the value of the <tt>gc.auto</tt> configuration variable, then\r
+all loose objects are combined into a single pack using\r
+<tt>git-repack -d -l</tt>. Setting the value of <tt>gc.auto</tt> to 0\r
+disables automatic packing of loose objects.</p>\r
+<p>If the number of packs exceeds the value of <tt>gc.autopacklimit</tt>,\r
+then existing packs (except those marked with a <tt>.keep</tt> file)\r
+are consolidated into a single pack by using the <tt>-A</tt> option of\r
+<tt>git-repack</tt>. Setting <tt>gc.autopacklimit</tt> to 0 disables\r
+automatic consolidation of packs.</p>\r
</dd>\r
</dl>\r
</div>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 03-Oct-2007 12:03:49 UTC\r
+Last updated 23-Oct-2007 01:21:49 UTC\r
</div>\r
</div>\r
</body>\r
Users are encouraged to run this task on a regular basis within
each repository to maintain good disk space utilization and good
-operating performance.
+operating performance. Some git commands may automatically run
+`git-gc`; see the `--auto` flag below for details.
OPTIONS
-------
few hundred changesets or so.
--auto::
- With this option, `git gc` checks if there are too many
- loose objects in the repository and runs
- gitlink:git-repack[1] with `-d -l` option to pack them.
- The threshold for loose objects is set with `gc.auto` configuration
- variable, and can be disabled by setting it to 0. Some
- Porcelain commands use this after they perform operation
- that could create many loose objects automatically.
- Additionally, when there are too many packs are present,
- they are consolidated into one larger pack by running
- the `git-repack` command with `-A` option. The
- threshold for number of packs is set with
- `gc.autopacklimit` configuration variable.
+ With this option, `git gc` checks whether any housekeeping is
+ required; if not, it exits without performing any work.
+ Some git commands run `git gc --auto` after performing
+ operations that could create many loose objects.
++
+Housekeeping is required if there are too many loose objects or
+too many packs in the repository. If the number of loose objects
+exceeds the value of the `gc.auto` configuration variable, then
+all loose objects are combined into a single pack using
+`git-repack -d -l`. Setting the value of `gc.auto` to 0
+disables automatic packing of loose objects.
++
+If the number of packs exceeds the value of `gc.autopacklimit`,
+then existing packs (except those marked with a `.keep` file)
+are consolidated into a single pack by using the `-A` option of
+`git-repack`. Setting `gc.autopacklimit` to 0 disables
+automatic consolidation of packs.
Configuration
-------------
a default name determined from the pack content. If\r
<pack-file> is not specified consider using --keep to\r
prevent a race condition between this process and\r
- <a href=":git-repack.html">:git-repack(1)</a> .\r
+ <a href=":git-repack.html">:git-repack(1)</a>.\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:09:43 UTC\r
+Last updated 23-Oct-2007 01:21:49 UTC\r
</div>\r
</div>\r
</body>\r
a default name determined from the pack content. If
<pack-file> is not specified consider using --keep to
prevent a race condition between this process and
- gitlink::git-repack[1] .
+ gitlink::git-repack[1].
--fix-thin::
It is possible for gitlink:git-pack-objects[1] to build
The HTTP daemon command-line that will be executed.\r
Command-line options may be specified here, and the\r
configuration file will be added at the end of the command-line.\r
- Currently, lighttpd and apache2 are the only supported servers.\r
+ Currently lighttpd, apache2 and webrick are supported.\r
(Default: lighttpd)\r
</p>\r
</dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:09:44 UTC\r
+Last updated 23-Oct-2007 01:21:50 UTC\r
</div>\r
</div>\r
</body>\r
The HTTP daemon command-line that will be executed.
Command-line options may be specified here, and the
configuration file will be added at the end of the command-line.
- Currently, lighttpd and apache2 are the only supported servers.
+ Currently lighttpd, apache2 and webrick are supported.
(Default: lighttpd)
-m|--module-path::
<p>If "git-merge-index" is called with multiple <file>s (or -a) then it\r
processes them in turn only stopping if merge returns a non-zero exit\r
code.</p>\r
-<p>Typically this is run with the a script calling git's imitation of\r
+<p>Typically this is run with a script calling git's imitation of\r
the merge command from the RCS package.</p>\r
<p>A sample script called "git-merge-one-file" is included in the\r
distribution.</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:09:46 UTC\r
+Last updated 23-Oct-2007 01:21:51 UTC\r
</div>\r
</div>\r
</body>\r
processes them in turn only stopping if merge returns a non-zero exit
code.
-Typically this is run with the a script calling git's imitation of
+Typically this is run with a script calling git's imitation of
the merge command from the RCS package.
A sample script called "git-merge-one-file" is included in the
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
<div class="verseblock">\r
-<div class="content"><em>git-push</em> [--all] [--tags] [--receive-pack=<git-receive-pack>]\r
+<div class="content"><em>git-push</em> [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]\r
[--repo=all] [-f | --force] [-v] [<repository> <refspec>…]</div></div>\r
</div>\r
<h2>DESCRIPTION</h2>\r
</p>\r
</dd>\r
<dt>\r
+--dry-run\r
+</dt>\r
+<dd>\r
+<p>\r
+ Do everything except actually send the updates.\r
+</p>\r
+</dd>\r
+<dt>\r
--tags\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Sep-2007 02:27:19 UTC\r
+Last updated 23-Oct-2007 01:21:51 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
[verse]
-'git-push' [--all] [--tags] [--receive-pack=<git-receive-pack>]
+'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
[--repo=all] [-f | --force] [-v] [<repository> <refspec>...]
DESCRIPTION
Instead of naming each ref to push, specifies that all
refs under `$GIT_DIR/refs/heads/` be pushed.
+\--dry-run::
+ Do everything except actually send the updates.
+
\--tags::
All refs under `$GIT_DIR/refs/tags` are pushed, in
addition to refspecs explicitly listed on the command
--onto option was supplied. This has the exact same effect as\r
<tt>git reset --hard <upstream></tt> (or <newbase>).</p>\r
<p>The commits that were previously saved into the temporary area are\r
-then reapplied to the current branch, one by one, in order.</p>\r
+then reapplied to the current branch, one by one, in order. Note that\r
+any commits in HEAD which introduce the same textual changes as a commit\r
+in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream\r
+with a different commit message or timestamp will be skipped).</p>\r
<p>It is possible that a merge failure will prevent this process from being\r
completely automatic. You will have to resolve any such merge failure\r
and run <tt>git rebase --continue</tt>. Another option is to bypass the commit\r
</div></div>\r
<p>The latter form is just a short-hand of <tt>git checkout topic</tt>\r
followed by <tt>git rebase master</tt>.</p>\r
+<p>If the upstream branch already contains a change you have made (e.g.,\r
+because you mailed a patch which was applied upstream), then that commit\r
+will be skipped. For example, running <tt>git-rebase master</tt> on the\r
+following history (in which A' and A introduce the same set of changes,\r
+but have different committer information):</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt> A---B---C topic\r
+ /\r
+ D---E---A'---F master</tt></pre>\r
+</div></div>\r
+<p>will result in:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt> B'---C' topic\r
+ /\r
+ D---E---A'---F master</tt></pre>\r
+</div></div>\r
<p>Here is how you would transplant a topic branch based on one\r
branch to another, to pretend that you forked the topic branch\r
from the latter branch, using <tt>rebase --onto</tt>.</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 30-Sep-2007 08:10:55 UTC\r
+Last updated 23-Oct-2007 01:21:54 UTC\r
</div>\r
</div>\r
</body>\r
`git reset --hard <upstream>` (or <newbase>).
The commits that were previously saved into the temporary area are
-then reapplied to the current branch, one by one, in order.
+then reapplied to the current branch, one by one, in order. Note that
+any commits in HEAD which introduce the same textual changes as a commit
+in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream
+with a different commit message or timestamp will be skipped).
It is possible that a merge failure will prevent this process from being
completely automatic. You will have to resolve any such merge failure
The latter form is just a short-hand of `git checkout topic`
followed by `git rebase master`.
+If the upstream branch already contains a change you have made (e.g.,
+because you mailed a patch which was applied upstream), then that commit
+will be skipped. For example, running `git-rebase master` on the
+following history (in which A' and A introduce the same set of changes,
+but have different committer information):
+
+------------
+ A---B---C topic
+ /
+ D---E---A'---F master
+------------
+
+will result in:
+
+------------
+ B'---C' topic
+ /
+ D---E---A'---F master
+------------
+
Here is how you would transplant a topic branch based on one
branch to another, to pretend that you forked the topic branch
from the latter branch, using `rebase --onto`.
<p>The command takes various subcommands, and different options\r
depending on the subcommand:</p>\r
<div class="verseblock">\r
-<div class="content">git reflog expire [--dry-run] [--stale-fix]\r
+<div class="content">git reflog expire [--dry-run] [--stale-fix] [--verbose]\r
[--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>…</div></div>\r
<p>git reflog [show] [log-options]</p>\r
<p>Reflog is a mechanism to record when the tip of branches are\r
Instead of listing <refs> explicitly, prune all refs.\r
</p>\r
</dd>\r
+<dt>\r
+--verbose\r
+</dt>\r
+<dd>\r
+<p>\r
+ Print extra information on screen.\r
+</p>\r
+</dd>\r
</dl>\r
</div>\r
<h2>Author</h2>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 25-Aug-2007 03:53:12 UTC\r
+Last updated 23-Oct-2007 01:21:56 UTC\r
</div>\r
</div>\r
</body>\r
depending on the subcommand:
[verse]
-git reflog expire [--dry-run] [--stale-fix]
+git reflog expire [--dry-run] [--stale-fix] [--verbose]
[--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...
git reflog [show] [log-options]
--all::
Instead of listing <refs> explicitly, prune all refs.
+--verbose::
+ Print extra information on screen.
+
Author
------
Written by Junio C Hamano <junkio@cox.net>
</div>\r
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
-<p><em>git-send-pack</em> [--all] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>…]</p>\r
+<p><em>git-send-pack</em> [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>…]</p>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
</p>\r
</dd>\r
<dt>\r
+--dry-run\r
+</dt>\r
+<dd>\r
+<p>\r
+ Do everything except actually send the updates.\r
+</p>\r
+</dd>\r
+<dt>\r
--force\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Sep-2007 02:27:20 UTC\r
+Last updated 23-Oct-2007 01:21:57 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
-'git-send-pack' [--all] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]
+'git-send-pack' [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]
DESCRIPTION
-----------
Instead of explicitly specifying which refs to update,
update all heads that locally exist.
+\--dry-run::
+ Do everything except actually send the updates.
+
\--force::
Usually, the command refuses to update a remote ref that
is not an ancestor of the local ref used to overwrite it.
</dt>\r
<dd>\r
<p>\r
- Show the changes recorded in the stash as a diff between the the\r
+ Show the changes recorded in the stash as a diff between the\r
stashed state and its original parent. When no <tt><stash></tt> is given,\r
shows the latest one. By default, the command shows the diffstat, but\r
it will accept any format known to <tt>git-diff</tt> (e.g., <tt>git-stash show\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 01-Oct-2007 16:22:45 UTC\r
+Last updated 23-Oct-2007 01:21:58 UTC\r
</div>\r
</div>\r
</body>\r
show [<stash>]::
- Show the changes recorded in the stash as a diff between the the
+ Show the changes recorded in the stash as a diff between the
stashed state and its original parent. When no `<stash>` is given,
shows the latest one. By default, the command shows the diffstat, but
it will accept any format known to `git-diff` (e.g., `git-stash show
</div>\r
<h2>BASIC EXAMPLES</h2>\r
<div class="sectionbody">\r
-<p>Tracking and contributing to a the trunk of a Subversion-managed project:</p>\r
+<p>Tracking and contributing to the trunk of a Subversion-managed project:</p>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt># Clone a repo (like git clone):\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Sep-2007 02:27:20 UTC\r
+Last updated 23-Oct-2007 01:22:01 UTC\r
</div>\r
</div>\r
</body>\r
BASIC EXAMPLES
--------------
-Tracking and contributing to a the trunk of a Subversion-managed project:
+Tracking and contributing to the trunk of a Subversion-managed project:
------------------------------------------------------------------------
# Clone a repo (like git clone):
</p>\r
</li>\r
</ol>\r
-<p>However, Git does <strong>not</strong> (and it should not)change tags behind\r
+<p>However, Git does <strong>not</strong> (and it should not) change tags behind\r
users back. So if somebody already got the old tag, doing a "git\r
pull" on your tree shouldn't just make them overwrite the old\r
one.</p>\r
they are most likely tracking with each other's progress by\r
having tracking branches. Again, the heuristic to automatically\r
follow such tags is a good thing.</p>\r
+<h3>On Backdating Tags</h3>\r
+<p>If you have imported some changes from another VCS and would like\r
+to add tags for major releases of your work, it is useful to be able\r
+to specify the date to embed inside of the tag object. The data in\r
+the tag object affects, for example, the ordering of tags in the\r
+gitweb interface.</p>\r
+<p>To set the date used in future tag objects, set the environment\r
+variable GIT_AUTHOR_DATE to one or more of the date and time. The\r
+date and time can be specified in a number of ways; the most common\r
+is "YYYY-MM-DD HH:MM".</p>\r
+<p>An example follows.</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ GIT_AUTHOR_DATE="2006-10-02 10:31" git tag -s v1.0.1</tt></pre>\r
+</div></div>\r
</div>\r
<h2>Author</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 28-Aug-2007 06:25:09 UTC\r
+Last updated 23-Oct-2007 01:22:00 UTC\r
</div>\r
</div>\r
</body>\r
others have already seen the old one. So just use "git tag -f"
again, as if you hadn't already published the old one.
-However, Git does *not* (and it should not)change tags behind
+However, Git does *not* (and it should not) change tags behind
users back. So if somebody already got the old tag, doing a "git
pull" on your tree shouldn't just make them overwrite the old
one.
follow such tags is a good thing.
+On Backdating Tags
+~~~~~~~~~~~~~~~~~~
+
+If you have imported some changes from another VCS and would like
+to add tags for major releases of your work, it is useful to be able
+to specify the date to embed inside of the tag object. The data in
+the tag object affects, for example, the ordering of tags in the
+gitweb interface.
+
+To set the date used in future tag objects, set the environment
+variable GIT_AUTHOR_DATE to one or more of the date and time. The
+date and time can be specified in a number of ways; the most common
+is "YYYY-MM-DD HH:MM".
+
+An example follows.
+
+------------
+$ GIT_AUTHOR_DATE="2006-10-02 10:31" git tag -s v1.0.1
+------------
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>,
</div>\r
<h2>File/Directory Structure</h2>\r
<div class="sectionbody">\r
-<p>Please see <a href="repository-layout.html">repository layout</a> document.</p>\r
+<p>Please see
the <a href="repository-layout.html">repository layout</a> document.</p>
\r <p>Read <a href="hooks.html">hooks</a> for more details about each hook.</p>\r
<p>Higher level SCMs may provide and manage additional information in the\r
<tt>$GIT_DIR</tt>.</p>\r
</div>\r
<h2>Terminology</h2>\r
<div class="sectionbody">\r
-<p>Please see <a href="glossary.html">glossary</a> document.</p>\r
+<p>Please see
the <a href="glossary.html">glossary</a> document.</p>
\r </div>\r
<h2>Environment Variables</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 04-Oct-2007 13:06:19 UTC\r
+Last updated 23-Oct-2007 01:22:09 UTC\r
</div>\r
</div>\r
</body>\r
File/Directory Structure
------------------------
-Please see link:repository-layout.html[repository layout] document.
+Please see the link:repository-layout.html[repository layout] document.
Read link:hooks.html[hooks] for more details about each hook.
Terminology
-----------
-Please see link:glossary.html[glossary] document.
+Please see the link:glossary.html[glossary] document.
Environment Variables
</p>\r
</dd>\r
<dt>\r
-gitk --max-count=100 --all — Makefile\r
+gitk --max-count=100 --all -- Makefile\r
</dt>\r
<dd>\r
<p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:10:00 UTC\r
+Last updated 23-Oct-2007 01:22:03 UTC\r
</div>\r
</div>\r
</body>\r
The "--" is necessary to avoid confusion with the *branch* named
'gitk'
-gitk --max-count=100 --all -- Makefile::
+gitk --max-count=100 --all \-- Makefile::
Show at most 100 changes made to the file 'Makefile'. Instead of only
looking for changes in the current branch look in all branches.
<p>\r
In <a href="#def_SCM">SCM</a> jargon, "cherry pick" means to choose a subset of\r
changes out of a series of changes (typically commits) and record them\r
- as a new series of changes on top of different codebase. In GIT, this is\r
- performed by "git cherry-pick" command to extract the change introduced\r
+ as a new series of changes on top of a different codebase. In GIT, this is\r
+ performed by the "git cherry-pick" command to extract the change introduced\r
by an existing <a href="#def_commit">commit</a> and to record it based on the tip\r
of the current <a href="#def_branch">branch</a> as a new commit.\r
</p>\r
<p>\r
The term <a href="#def_pickaxe">pickaxe</a> refers to an option to the diffcore\r
routines that help select changes that add or delete a given text\r
- string. With the —pickaxe-all option, it can be used to view the full\r
+ string. With the <tt>—pickaxe-all</tt> option, it can be used to view the full\r
<a href="#def_changeset">changeset</a> that introduced or removed, say, a\r
particular line of text. See <a href="git-diff.html">git-diff(1)</a>.\r
</p>\r
<p>\r
Pushing a <a href="#def_branch">branch</a> means to get the branch's\r
<a href="#def_head_ref">head ref</a> from a remote <a href="#def_repository">repository</a>,\r
- find out if it is an ancestor to the branch's local\r
- head ref is a direct, and in that case, putting all\r
+ find out if it is a direct ancestor to the branch's local\r
+ head ref, and in that case, putting all\r
objects, which are <a href="#def_reachable">reachable</a> from the local\r
head ref, and which are missing from the remote\r
repository, into the remote\r
it as my origin branch head". And <tt>git push\r
$URL refs/heads/master:refs/heads/to-upstream</tt> means "publish my\r
master branch head as to-upstream branch at $URL". See also\r
- <a href="git-push.html">git-push(1)</a>\r
+ <a href="git-push.html">git-push(1)</a>.\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:10:10 UTC\r
+Last updated 23-Oct-2007 01:22:08 UTC\r
</div>\r
</div>\r
</body>\r
[[def_cherry-picking]]cherry-picking::
In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of
changes out of a series of changes (typically commits) and record them
- as a new series of changes on top of different codebase. In GIT, this is
- performed by "git cherry-pick" command to extract the change introduced
+ as a new series of changes on top of a different codebase. In GIT, this is
+ performed by the "git cherry-pick" command to extract the change introduced
by an existing <<def_commit,commit>> and to record it based on the tip
of the current <<def_branch,branch>> as a new commit.
[[def_pickaxe]]pickaxe::
The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore
routines that help select changes that add or delete a given text
- string. With the --pickaxe-all option, it can be used to view the full
+ string. With the `--pickaxe-all` option, it can be used to view the full
<<def_changeset,changeset>> that introduced or removed, say, a
particular line of text. See gitlink:git-diff[1].
[[def_push]]push::
Pushing a <<def_branch,branch>> means to get the branch's
<<def_head_ref,head ref>> from a remote <<def_repository,repository>>,
- find out if it is an ancestor to the branch's local
- head ref is a direct, and in that case, putting all
+ find out if it is a direct ancestor to the branch's local
+ head ref, and in that case, putting all
objects, which are <<def_reachable,reachable>> from the local
head ref, and which are missing from the remote
repository, into the remote
it as my origin branch head". And `git push
$URL refs/heads/master:refs/heads/to-upstream` means "publish my
master branch head as to-upstream branch at $URL". See also
- gitlink:git-push[1]
+ gitlink:git-push[1].
[[def_repository]]repository::
A collection of <<def_ref,refs>> together with an
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Git User's Manual (for version 1.5.3 or newer)</title><link rel="stylesheet" href="docbook-xsl.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.69.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="id189136"></a>Git User's Manual (for version 1.5.3 or newer)</h1></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="#id264725">Preface</a></span></dt><dt><span class="chapter"><a href="#repositories-and-branches">1. Repositories and Branches</a></span></dt><dd><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-with-git-fetch">Updating a repository with git fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></dd><dt><span class="chapter"><a href="#exploring-git-history">2. Exploring git history</a></span></dt><dd><dl><dt><span class="section"><a href="#using-bisect">How to use bisect to find a regression</a></span></dt><dt><span class="section"><a href="#naming-commits">Naming commits</a></span></dt><dt><span class="section"><a href="#creating-tags">Creating tags</a></span></dt><dt><span class="section"><a href="#browsing-revisions">Browsing revisions</a></span></dt><dt><span class="section"><a href="#generating-diffs">Generating diffs</a></span></dt><dt><span class="section"><a href="#viewing-old-file-versions">Viewing old file versions</a></span></dt><dt><span class="section"><a href="#history-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#counting-commits-on-a-branch">Counting the number of commits on a branch</a></span></dt><dt><span class="section"><a href="#checking-for-equal-branches">Check whether two branches point at the same history</a></span></dt><dt><span class="section"><a href="#finding-tagged-descendants">Find first tagged version including a given fix</a></span></dt><dt><span class="section"><a href="#showing-commits-unique-to-a-branch">Showing commits unique to a given branch</a></span></dt><dt><span class="section"><a href="#making-a-release">Creating a changelog and tarball for a software release</a></span></dt><dt><span class="section"><a href="#Finding-comments-with-given-content">Finding commits referencing a file with given content</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#Developing-with-git">3. Developing with git</a></span></dt><dd><dl><dt><span class="section"><a href="#telling-git-your-name">Telling git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-editing-history">Fixing a mistake by editing history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#sharing-development">4. Sharing development with others</a></span></dt><dd><dl><dt><span class="section"><a href="#getting-updates-with-git-pull">Getting updates with git pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a git repository via the git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via http</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#cleaning-up-history">5. Rewriting history and maintaining patch series</a></span></dt><dd><dl><dt><span class="section"><a href="#patch-series">Creating the perfect patch series</a></span></dt><dt><span class="section"><a href="#using-git-rebase">Keeping a patch series up to date using git-rebase</a></span></dt><dt><span class="section"><a href="#modifying-one-commit">Modifying a single commit</a></span></dt><dt><span class="section"><a href="#reordering-patch-series">Reordering or selecting from a patch series</a></span></dt><dt><span class="section"><a href="#patch-series-tools">Other tools</a></span></dt><dt><span class="section"><a href="#problems-with-rewriting-history">Problems with rewriting history</a></span></dt></dl></dd><dt><span class="chapter"><a href="#advanced-branch-management">6. Advanced branch management</a></span></dt><dd><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote branches</a></span></dt></dl></dd><dt><span class="chapter"><a href="#git-concepts">7. Git concepts</a></span></dt><dd><dl><dt><span class="section"><a href="#the-object-database">The Object Database</a></span></dt><dd><dl><dt><span class="section"><a href="#commit-object">Commit Object</a></span></dt><dt><span class="section"><a href="#tree-object">Tree Object</a></span></dt><dt><span class="section"><a href="#blob-object">Blob Object</a></span></dt><dt><span class="section"><a href="#trust">Trust</a></span></dt><dt><span class="section"><a href="#tag-object">Tag Object</a></span></dt><dt><span class="section"><a href="#pack-files">How git stores objects efficiently: pack files</a></span></dt><dt><span class="section"><a href="#dangling-objects">Dangling objects</a></span></dt></dl></dd><dt><span class="section"><a href="#the-index">The index</a></span></dt></dl></dd><dt><span class="chapter"><a href="#submodules">8. Submodules</a></span></dt><dd><dl><dt><span class="section"><a href="#id279
699">Pitfalls with submodules</a></span></dt></dl></dd><dt><span class="chapter"><a href="#low-level-operations">9. Low-level git operations</a></span></dt><dd><dl><dt><span class="section"><a href="#object-manipulation">Object access and manipulation</a></span></dt><dt><span class="section"><a href="#the-workflow">The Workflow</a></span></dt><dd><dl><dt><span class="section"><a href="#working-directory-to-index">working directory -> index</a></span></dt><dt><span class="section"><a href="#index-to-object-database">index -> object database</a></span></dt><dt><span class="section"><a href="#object-database-to-index">object database -> index</a></span></dt><dt><span class="section"><a href="#index-to-working-directory">index -> working directory</a></span></dt><dt><span class="section"><a href="#tying-it-all-together">Tying it all together</a></span></dt></dl></dd><dt><span class="section"><a href="#examining-the-data">Examining the data</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees">Merging multiple trees</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees-2">Merging multiple trees, continued</a></span></dt></dl></dd><dt><span class="chapter"><a href="#hacking-git">10. Hacking git</a></span></dt><dd><dl><dt><span class="section"><a href="#object-details">Object storage format</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git's source code</a></span></dt></dl></dd><dt><span class="chapter"><a href="#glossary">11. GIT Glossary</a></span></dt><dt><span class="appendix"><a href="#git-quick-start">A. Git Quick Reference</a></span></dt><dd><dl><dt><span class="section"><a href="#quick-creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#managing-branches">Managing branches</a></span></dt><dt><span class="section"><a href="#exploring-history">Exploring history</a></span></dt><dt><span class="section"><a href="#making-changes">Making changes</a></span></dt><dt><span class="section"><a href="#merging">Merging</a></span></dt><dt><span class="section"><a href="#sharing-your-changes">Sharing your changes</a></span></dt><dt><span class="section"><a href="#repository-maintenance">Repository maintenance</a></span></dt></dl></dd><dt><span class="appendix"><a href="#todo">B. Notes and todo list for this manual</a></span></dt></dl></div><div class="preface" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id264725"></a>Preface</h2></div></div></div><p>Git is a fast distributed revision control system.</p><p>This manual is designed to be readable by someone with basic UNIX
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Git User's Manual (for version 1.5.3 or newer)</title><link rel="stylesheet" href="docbook-xsl.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.69.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="id189136"></a>Git User's Manual (for version 1.5.3 or newer)</h1></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="#id264725">Preface</a></span></dt><dt><span class="chapter"><a href="#repositories-and-branches">1. Repositories and Branches</a></span></dt><dd><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-with-git-fetch">Updating a repository with git fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></dd><dt><span class="chapter"><a href="#exploring-git-history">2. Exploring git history</a></span></dt><dd><dl><dt><span class="section"><a href="#using-bisect">How to use bisect to find a regression</a></span></dt><dt><span class="section"><a href="#naming-commits">Naming commits</a></span></dt><dt><span class="section"><a href="#creating-tags">Creating tags</a></span></dt><dt><span class="section"><a href="#browsing-revisions">Browsing revisions</a></span></dt><dt><span class="section"><a href="#generating-diffs">Generating diffs</a></span></dt><dt><span class="section"><a href="#viewing-old-file-versions">Viewing old file versions</a></span></dt><dt><span class="section"><a href="#history-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#counting-commits-on-a-branch">Counting the number of commits on a branch</a></span></dt><dt><span class="section"><a href="#checking-for-equal-branches">Check whether two branches point at the same history</a></span></dt><dt><span class="section"><a href="#finding-tagged-descendants">Find first tagged version including a given fix</a></span></dt><dt><span class="section"><a href="#showing-commits-unique-to-a-branch">Showing commits unique to a given branch</a></span></dt><dt><span class="section"><a href="#making-a-release">Creating a changelog and tarball for a software release</a></span></dt><dt><span class="section"><a href="#Finding-comments-with-given-content">Finding commits referencing a file with given content</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#Developing-with-git">3. Developing with git</a></span></dt><dd><dl><dt><span class="section"><a href="#telling-git-your-name">Telling git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-editing-history">Fixing a mistake by editing history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#sharing-development">4. Sharing development with others</a></span></dt><dd><dl><dt><span class="section"><a href="#getting-updates-with-git-pull">Getting updates with git pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a git repository via the git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via http</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#cleaning-up-history">5. Rewriting history and maintaining patch series</a></span></dt><dd><dl><dt><span class="section"><a href="#patch-series">Creating the perfect patch series</a></span></dt><dt><span class="section"><a href="#using-git-rebase">Keeping a patch series up to date using git-rebase</a></span></dt><dt><span class="section"><a href="#modifying-one-commit">Modifying a single commit</a></span></dt><dt><span class="section"><a href="#reordering-patch-series">Reordering or selecting from a patch series</a></span></dt><dt><span class="section"><a href="#patch-series-tools">Other tools</a></span></dt><dt><span class="section"><a href="#problems-with-rewriting-history">Problems with rewriting history</a></span></dt></dl></dd><dt><span class="chapter"><a href="#advanced-branch-management">6. Advanced branch management</a></span></dt><dd><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote branches</a></span></dt></dl></dd><dt><span class="chapter"><a href="#git-concepts">7. Git concepts</a></span></dt><dd><dl><dt><span class="section"><a href="#the-object-database">The Object Database</a></span></dt><dd><dl><dt><span class="section"><a href="#commit-object">Commit Object</a></span></dt><dt><span class="section"><a href="#tree-object">Tree Object</a></span></dt><dt><span class="section"><a href="#blob-object">Blob Object</a></span></dt><dt><span class="section"><a href="#trust">Trust</a></span></dt><dt><span class="section"><a href="#tag-object">Tag Object</a></span></dt><dt><span class="section"><a href="#pack-files">How git stores objects efficiently: pack files</a></span></dt><dt><span class="section"><a href="#dangling-objects">Dangling objects</a></span></dt></dl></dd><dt><span class="section"><a href="#the-index">The index</a></span></dt></dl></dd><dt><span class="chapter"><a href="#submodules">8. Submodules</a></span></dt><dd><dl><dt><span class="section"><a href="#id279
798">Pitfalls with submodules</a></span></dt></dl></dd><dt><span class="chapter"><a href="#low-level-operations">9. Low-level git operations</a></span></dt><dd><dl><dt><span class="section"><a href="#object-manipulation">Object access and manipulation</a></span></dt><dt><span class="section"><a href="#the-workflow">The Workflow</a></span></dt><dd><dl><dt><span class="section"><a href="#working-directory-to-index">working directory -> index</a></span></dt><dt><span class="section"><a href="#index-to-object-database">index -> object database</a></span></dt><dt><span class="section"><a href="#object-database-to-index">object database -> index</a></span></dt><dt><span class="section"><a href="#index-to-working-directory">index -> working directory</a></span></dt><dt><span class="section"><a href="#tying-it-all-together">Tying it all together</a></span></dt></dl></dd><dt><span class="section"><a href="#examining-the-data">Examining the data</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees">Merging multiple trees</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees-2">Merging multiple trees, continued</a></span></dt></dl></dd><dt><span class="chapter"><a href="#hacking-git">10. Hacking git</a></span></dt><dd><dl><dt><span class="section"><a href="#object-details">Object storage format</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git's source code</a></span></dt></dl></dd><dt><span class="chapter"><a href="#glossary">11. GIT Glossary</a></span></dt><dt><span class="appendix"><a href="#git-quick-start">A. Git Quick Reference</a></span></dt><dd><dl><dt><span class="section"><a href="#quick-creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#managing-branches">Managing branches</a></span></dt><dt><span class="section"><a href="#exploring-history">Exploring history</a></span></dt><dt><span class="section"><a href="#making-changes">Making changes</a></span></dt><dt><span class="section"><a href="#merging">Merging</a></span></dt><dt><span class="section"><a href="#sharing-your-changes">Sharing your changes</a></span></dt><dt><span class="section"><a href="#repository-maintenance">Repository maintenance</a></span></dt></dl></dd><dt><span class="appendix"><a href="#todo">B. Notes and todo list for this manual</a></span></dt></dl></div><div class="preface" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id264725"></a>Preface</h2></div></div></div><p>Git is a fast distributed revision control system.</p><p>This manual is designed to be readable by someone with basic UNIX
command-line skills, but no previous knowledge of git.</p><p><a href="#repositories-and-branches" title="Chapter 1. Repositories and Branches">Chapter 1, <i>Repositories and Branches</i></a> and <a href="#exploring-git-history" title="Chapter 2. Exploring git history">Chapter 2, <i>Exploring git history</i></a> explain how
to fetch and study a project using git—read these chapters to learn how
to build and test a particular version of a software project, search for
echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new"</p></div><p>and then he just cut-and-pastes the output commands after verifying that
they look OK.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="Finding-comments-with-given-content"></a>Finding commits referencing a file with given content</h3></div></div></div><p>Somebody hands you a copy of a file, and asks which commits modified a
file such that it contained the given content either before or after the
-commit. You can find out with this:</p><div class="literallayout"><p>$ git log --raw --abbrev=40 --pretty=oneline -- filename |<br>
+commit. You can find out with this:</p><div class="literallayout"><p>$ git log --raw --abbrev=40 --pretty=oneline |<br>
grep -B 1 `git hash-object filename`</p></div><p>Figuring out why this works is left as an exercise to the (advanced)
student. The <a href="git-log.html" target="_top">git-log(1)</a>, <a href="git-diff-tree.html" target="_top">git-diff-tree(1)</a>, and
<a href="git-hash-object.html" target="_top">git-hash-object(1)</a> man pages may prove helpful.</p></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="Developing-with-git"></a>Chapter 3. Developing with git</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#telling-git-your-name">Telling git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-editing-history">Fixing a mistake by editing history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="telling-git-your-name"></a>Telling git your name</h2></div></div></div><p>Before creating any commits, you should introduce yourself to git. The
current branch. Then you can make your fix as usual.</p><div class="literallayout"><p>... edit and test ...<br>
$ git commit -a -m "blorpl: typofix"</p></div><p>After that, you can go back to what you were working on with
<code class="literal">git stash apply</code>:</p><div class="literallayout"><p>$ git stash apply</p></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="ensuring-good-performance"></a>Ensuring good performance</h2></div></div></div><p>On large repositories, git depends on compression to keep the history
-information from taking up to much space on disk or in memory.</p><p>This compression is not performed automatically. Therefore you
+information from taking up to
o much space on disk or in memory.</p><p>This compression is not performed automatically. Therefore you
should occasionally run <a href="git-gc.html" target="_top">git-gc(1)</a>:</p><div class="literallayout"><p>$ git gc</p></div><p>to recompress the archive. This can be very time-consuming, so
you may prefer to run git-gc when you are not doing other work.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="ensuring-reliability"></a>Ensuring reliability</h2></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="checking-for-corruption"></a>Checking the repository for corruption</h3></div></div></div><p>The <a href="git-fsck.html" target="_top">git-fsck(1)</a> command runs a number of self-consistency checks
on the repository, and reports on any problems. This may take some
...</p></div><p>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 for
recovering lost work—see <a href="#dangling-objects" title="Dangling objects">the section called “Dangling objects”</a> for details. However, if
-you wish, you can remove them with <a href="git-prune.html" target="_top">git-prune(1)</a> or the —prune
+you wish, you can remove them with <a href="git-prune.html" target="_top">git-prune(1)</a> or the <code class="literal">—prune</code>
option to <a href="git-gc.html" target="_top">git-gc(1)</a>:</p><div class="literallayout"><p>$ git gc --prune</p></div><p>This may be time-consuming. Unlike most other git operations (including
git-gc when run without any options), it is not safe to prune while
-other git operations are in progress in the same repository.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="recovering-lost-changes"></a>Recovering lost changes</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="reflogs"></a>Reflogs</h4></div></div></div><p>Say you modify a branch with <a href="git-reset.html" target="_top">git-reset(1)</a> —hard, and then
+other git operations are in progress in the same repository.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="recovering-lost-changes"></a>Recovering lost changes</h3></div></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="reflogs"></a>Reflogs</h4></div></div></div><p>Say you modify a branch with <code class="literal"><a href="git-reset.html" target="_top">git-reset(1)</a> —hard</code>, and then
realize that the branch was the only reference you had to that point in
history.</p><p>Fortunately, git also keeps a log, called a "reflog", of all the
previous values of each branch. So in this case you can still find the
accomplish the above with just a simple</p><div class="literallayout"><p>$ git pull</p></div><p>More generally, a branch that is created from a remote branch will pull
by default from that branch. See the descriptions of the
branch.<name>.remote and branch.<name>.merge options in
-<a href="git-config.html" target="_top">git-config(1)</a>, and the discussion of the —track option in
+<a href="git-config.html" target="_top">git-config(1)</a>, and the discussion of the <code class="literal">—track</code> option in
<a href="git-checkout.html" target="_top">git-checkout(1)</a>, to learn how to control these defaults.</p><p>In addition to saving you keystrokes, "git pull" also helps you by
producing a default commit message documenting the branch and
repository that you pulled from.</p><p>(But note that no such commit will be created in the case of a
you can just pull changes from each other's repositories directly;
commands that accept repository URLs as arguments will also accept a
local directory name:</p><div class="literallayout"><p>$ git clone /path/to/repository<br>
-$ git pull /path/to/other/repository</p></div><p>or an ssh
url:</p><div class="literallayout"><p>$ git clone ssh://yourhost/~you/repository</p></div><p>For projects with few developers, or for synchronizing a few private
+$ git pull /path/to/other/repository</p></div><p>or an ssh
URL:</p><div class="literallayout"><p>$ git clone ssh://yourhost/~you/repository</p></div><p>For projects with few developers, or for synchronizing a few private
repositories, this may be all you need.</p><p>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
around it.</p><p>Next, copy proj.git to the server where you plan to host the
public repository. You can use scp, rsync, or whatever is most
convenient.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="exporting-via-git"></a>Exporting a git repository via the git protocol</h3></div></div></div><p>This is the preferred method.</p><p>If someone else administers the server, they should tell you what
-directory to put the repository in, and what git:// url it will appear
+directory to put the repository in, and what git:// URL it will appear
at. You can then skip to the section
"<a href="#pushing-changes-to-a-public-repository" title="Pushing changes to a public repository">Pushing changes to a public repository</a>", below.</p><p>Otherwise, all you need to do is start <a href="git-daemon.html" target="_top">git-daemon(1)</a>; it will
listen on port 9418. By default, it will allow access to any directory
$ git --bare update-server-info<br>
$ chmod a+x hooks/post-update</p></div><p>(For an explanation of the last two lines, see
<a href="git-update-server-info.html" target="_top">git-update-server-info(1)</a>, and the documentation
-<a href="hooks.html" target="_top">Hooks used by git</a>.)</p><p>Advertise the url of proj.git. Anybody else should then be able to
-clone or pull from that
url, for example with a command line like:</p><div class="literallayout"><p>$ git clone http://yourserver.com/~you/proj.git</p></div><p>(See also
+<a href="hooks.html" target="_top">Hooks used by git</a>.)</p><p>Advertise the URL of proj.git. Anybody else should then be able to
+clone or pull from that
URL, for example with a command line like:</p><div class="literallayout"><p>$ git clone http://yourserver.com/~you/proj.git</p></div><p>(See also
<a href="howto/setup-git-server-over-http.txt" target="_top">setup-git-server-over-http</a>
for a slightly more sophisticated setup using WebDAV which also
allows pushing over http.)</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="pushing-changes-to-a-public-repository"></a>Pushing changes to a public repository</h3></div></div></div><p>Note that the two techniques outlined above (exporting via
a <a href="#fast-forwards" title="Fast-forward merges">fast forward</a>. Normally this is a sign of
something wrong. However, if you are sure you know what you're
doing, you may force git-push to perform the update anyway by
-pr
oceeding the branch name by a plus sign:</p><div class="literallayout"><p>$ git push ssh://yourserver.com/~you/proj.git +master</p></div><p>Note that the target of a "push" is normally a
+pr
eceding the branch name by a plus sign:</p><div class="literallayout"><p>$ git push ssh://yourserver.com/~you/proj.git +master</p></div><p>Note that the target of a "push" is normally a
<a href="#def_bare_repository">bare</a> 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
at the current tip of origin/master branch, and should be set up (using
the —track option to <a href="git-branch.html" target="_top">git-branch(1)</a>) to merge changes in from
Linus by default.</p><div class="literallayout"><p>$ git branch --track test origin/master<br>
-$ git branch --track release origin/master</p></div><p>These can be easily kept up to date using <a href="git-pull.html" target="_top">git-pull(1)</a></p><div class="literallayout"><p>$ git checkout test && git pull<br>
+$ git branch --track release origin/master</p></div><p>These can be easily kept up to date using <a href="git-pull.html" target="_top">git-pull(1)</a>
.</p><div class="literallayout"><p>$ git checkout test && git pull<br>
$ git checkout release && git pull</p></div><p>Important note! If you have any local changes in these branches, then
this merge will create a commit object in the history (with no local
changes git will simply do a "Fast forward" merge). Many people dislike
means that the patches can be moved into the "release" tree in any order.</p><div class="literallayout"><p>$ git checkout release && git pull . speed-up-spinlocks</p></div><p>After a while, you will have a number of branches, and despite the
well chosen names you picked for each of them, you may forget what
they are for, or what status they are in. To get a reminder of what
-changes are in a specific branch, use:</p><div class="literallayout"><p>$ git log linux..branchname | git-shortlog</p></div><p>To see whether it has already been merged into the test or release branches
-use:</p><div class="literallayout"><p>$ git log test..branchname</p></div><p>or</p><div class="literallayout"><p>$ git log release..branchname</p></div><p>(If this branch has not yet been merged you will see some log entries.
+changes are in a specific branch, use:</p><div class="literallayout"><p>$ git log linux..branchname | git-shortlog</p></div><p>To see whether it has already been merged into the test or release branches,
+use:</p><div class="literallayout"><p>$ git log test..branchname</p></div><p>or</p><div class="literallayout"><p>$ git log release..branchname</p></div><p>(If this branch has not yet been merged, you will see some log entries.
If it has been merged, then there will be no output.)</p><p>Once a patch completes the great cycle (moving from test to release,
then pulled by Linus, and finally coming back into your local
-"origin/master" branch) the branch for this change is no longer needed.
+"origin/master" branch), the branch for this change is no longer needed.
You detect this when the output from:</p><div class="literallayout"><p>$ git log origin..branchname</p></div><p>is empty. At this point the branch can be deleted:</p><div class="literallayout"><p>$ git branch -d branchname</p></div><p>Some changes are so trivial that it is not necessary to create a separate
branch and then merge into each of the test and release branches. For
these changes, just apply directly to the "release" branch, and then
a'--b'--c' <-- mywork</pre><p>In the process, it may discover conflicts. In that case it will stop
and allow you to fix the conflicts; after fixing conflicts, use "git
add" to update the index with those contents, and then, instead of
-running git-commit, just run</p><div class="literallayout"><p>$ git rebase --continue</p></div><p>and git will continue applying the rest of the patches.</p><p>At any point you may use the —abort option to abort this process and
+running git-commit, just run</p><div class="literallayout"><p>$ git rebase --continue</p></div><p>and git will continue applying the rest of the patches.</p><p>At any point you may use the <code class="literal">—abort</code> option to abort this process and
return mywork to the state it had before you started the rebase:</p><div class="literallayout"><p>$ git rebase --abort</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="modifying-one-commit"></a>Modifying a single commit</h2></div></div></div><p>We saw in <a href="#fixing-a-mistake-by-editing-history" title="Fixing a mistake by editing history">the section called “Fixing a mistake by editing history”</a> that you can replace the
most recent commit using</p><div class="literallayout"><p>$ git commit --amend</p></div><p>which will replace the old commit by a new commit incorporating your
changes, giving you a chance to edit the old commit message first.</p><p>You can also use a combination of this and <a href="git-rebase.html" target="_top">git-rebase(1)</a> to edit
allows you to apply the change introduced by that commit and create a
new commit that records it. So, for example, if "mywork" points to a
series of patches on top of "origin", you might do something like:</p><div class="literallayout"><p>$ git checkout -b mywork-new origin<br>
-$ gitk origin..mywork &</p></div><p>And browse through the list of patches in the mywork branch using gitk,
+$ gitk origin..mywork &</p></div><p>and browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
-cherry-pick, and possibly modifying them as you go using commit —amend.
+cherry-pick, and possibly modifying them as you go using <code class="literal">commit —amend</code>.
The <a href="git-gui.html" target="_top">git-gui(1)</a> command may also help as it allows you to
individually select diff hunks for inclusion in the index (by
right-clicking on the diff hunk and choosing "Stage Hunk for Commit").</p><p>Another technique is to use git-format-patch to create a series of
Git can quickly determine whether two objects are identical or not,
just by comparing names.
</li><li>
-Since object names are computed the same way in ever repository, the
+Since object names are computed the same way in every repository, the
same content stored in two repositories will always be stored under
the same name.
</li><li>
can refer to other tree objects, thus creating a directory hierarchy.
</li><li>
A <a href="#def_commit_object">"commit" object</a> ties such directory hierarchies
- together into a <a href="#def_DAG">directed acyclic graph</a> of revisions - each
+ together into a <a href="#def_DAG">directed acyclic graph</a> of revisions—each
commit contains the object name of exactly one tree designating the
directory hierarchy at the time of the commit. In addition, a commit
refers to "parent" commit objects that describe the history of how we
example, a "dangling blob" may arise because you did a "git add" of a
file, but then, before you actually committed it and made it part of the
bigger picture, you changed something else in that file and committed
-that <span class="strong"><strong>updated</strong></span> thing - the old state that you added originally ends up
+that <span class="strong"><strong>updated</strong></span> thing—the old state that you added originally ends up
not being pointed to by any commit or tree, so it's now a dangling blob
object.</p><p>Similarly, when the "recursive" merge strategy runs, and finds that
there are criss-cross merges and thus more than one merge base (which is
up pointing to them, so they end up "dangling" in your repository.</p><p>Generally, dangling objects aren't anything to worry about. They can
even be very useful: if you screw something up, the dangling objects can
be how you recover your old tree (say, you did a rebase, and realized
-that you really didn't want to - you can look at what dangling objects
+that you really didn't want to—you can look at what dangling objects
you have, and decide to reset your head to some old dangling state).</p><p>For commits, you can just use:</p><div class="literallayout"><p>$ gitk <dangling-commit-sha-goes-here> --not --all</p></div><p>This asks for all the history reachable from the given commit but not
from any branch, tag, or other reference. If you decide it's something
you want, you can always create a new reference to it, e.g.,</p><div class="literallayout"><p>$ git branch recovered-branch <dangling-commit-sha-goes-here></p></div><p>For blobs and trees, you can't do the same, but you can still examine
leaving _some_ of the new objects in the object database, but just
dangling and useless.</p><p>Anyway, once you are sure that you're not interested in any dangling
state, you can just prune all unreachable objects:</p><div class="literallayout"><p>$ git prune</p></div><p>and they'll be gone. But you should only run "git prune" on a quiescent
-repository - it's kind of like doing a filesystem fsck recovery: you
-don't want to do that while the filesystem is mounted.</p><p>(The same is true of "git-fsck" itself, btw - but since
+repository—it's kind of like doing a filesystem fsck recovery: you
+don't want to do that while the filesystem is mounted.</p><p>(The same is true of "git-fsck" itself, btw, but since
git-fsck never actually <span class="strong"><strong>changes</strong></span> the repository, it just reports
on what it found, git-fsck itself is never "dangerous" to run.
Running it while somebody is actually changing the repository can cause
number, and will take on values other than 0 for files with merge
conflicts.</p></li></ol></div><p>The index is thus a sort of temporary staging area, which is filled with
a tree which you are in the process of working on.</p><p>If you blow the index away entirely, you generally haven't lost any
-information as long as you have the name of the tree that it described.</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="submodules"></a>Chapter 8. Submodules</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id279
699">Pitfalls with submodules</a></span></dt></dl></div><p>Large projects are often composed of smaller, self-contained modules. For
+information as long as you have the name of the tree that it described.</p></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="submodules"></a>Chapter 8. Submodules</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="section"><a href="#id279
798">Pitfalls with submodules</a></span></dt></dl></div><p>Large projects are often composed of smaller, self-contained modules. For
example, an embedded Linux distribution's source tree would include every
piece of software in the distribution with some local modifications; a movie
player might need to build against a specific, known-working version of a
$ git add a<br>
$ git commit -m "Updated submodule a."<br>
$ git push</p></div><p>You have to run <code class="literal">git submodule update</code> after <code class="literal">git pull</code> if you want to update
-submodules, too.</p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id279
699"></a>Pitfalls with submodules</h2></div></div></div><p>Always publish the submodule change before publishing the change to the
+submodules, too.</p><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id279
798"></a>Pitfalls with submodules</h2></div></div></div><p>Always publish the submodule change before publishing the change to the
superproject that references it. If you forget to publish the submodule change,
others won't be able to clone the repository:</p><div class="literallayout"><p>$ cd ~/git/super/a<br>
$ echo i added another line to this file >> a.txt<br>
<a href="git-diff-tree.html" target="_top">git-diff-tree(1)</a>.</p><p>A tag is created with <a href="git-mktag.html" target="_top">git-mktag(1)</a>, and the signature can be
verified by <a href="git-verify-tag.html" target="_top">git-verify-tag(1)</a>, though it is normally simpler to
use <a href="git-tag.html" target="_top">git-tag(1)</a> for both.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="the-workflow"></a>The Workflow</h2></div></div></div><p>High-level operations such as <a href="git-commit.html" target="_top">git-commit(1)</a>,
-<a href="git-checkout.html" target="_top">git-checkout(1)</a> and git-reset[1] work by moving data between the
-working tree, the index, and the object database. Git provides
-low-level operations which perform each of these steps individually.</p><p>Generally, all "git" operations work on the index file. Some operations
+<a href="git-checkout.html" target="_top">git-checkout(1)</a> and <a href="git-reset.html" target="_top">git-reset(1)</a> work by moving data
+between the working tree, the index, and the object database. Git
+provides low-level operations which perform each of these steps
+individually.</p><p>Generally, all "git" operations work on the index file. Some operations
work <span class="strong"><strong>purely</strong></span> on the index file (showing the current state of the
index), but most operations move data between the index file and either
the database or the working directory. Thus there are four main
stat information. It will <span class="emphasis"><em>not</em></span> update the object status itself, and
it will only update the fields that are used to quickly test whether
an object still matches its old backing store object.</p><p>The previously introduced <a href="git-add.html" target="_top">git-add(1)</a> is just a wrapper for
-<a href="git-update-index.html" target="_top">git-update-index(1)</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="index-to-object-database"></a>index -> object database</h3></div></div></div><p>You write your current index file to a "tree" object with the program</p><div class="literallayout"><p>$ git write-tree</p></div><p>that doesn't come with any options - it will just write out the
+<a href="git-update-index.html" target="_top">git-update-index(1)</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="index-to-object-database"></a>index -> object database</h3></div></div></div><p>You write your current index file to a "tree" object with the program</p><div class="literallayout"><p>$ git write-tree</p></div><p>that doesn't come with any options—it will just write out the
current index into the set of tree objects that describe that state,
and it will return the name of the resulting top-level tree. You can
use that tree to re-generate the index at any time by going in the
other direction:</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="object-database-to-index"></a>object database -> index</h3></div></div></div><p>You read a "tree" file from the object database, and use that to
-populate (and overwrite - don't do this if your index contains any
+populate (and overwrite—don't do this if your index contains any
unsaved state that you might want to restore later!) your current
index. Normal operation is just</p><div class="literallayout"><p>$ git-read-tree <sha1 of tree></p></div><p>and your index file will now be equivalent to the tree that you saved
earlier. However, that is only your <span class="emphasis"><em>index</em></span> file: your working
<span class="emphasis"><em>force</em></span> the checkout.</p><p>Finally, there are a few odds and ends which are not purely moving
from one representation to the other:</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="tying-it-all-together"></a>Tying it all together</h3></div></div></div><p>To commit a tree you have instantiated with "git-write-tree", you'd
create a "commit" object that refers to that tree and the history
-behind it - most notably the "parent" commits that preceded it in
+behind it—most notably the "parent" commits that preceded it in
history.</p><p>Normally a "commit" has one parent: the previous state of the tree
before a certain change was made. However, sometimes it can have two
or more parent commits, in which case we call it a "merge", due to the
tree, aka the common tree, and the two "result" trees, aka the branches
you want to merge), you do a "merge" read into the index. This will
complain if it has to throw away your old index contents, so you should
-make sure that you've committed those - in fact you would normally
+make sure that you've committed those—in fact you would normally
always do a merge against your last commit (which should thus match what
you have in your current index anyway).</p><p>To do the merge, do</p><div class="literallayout"><p>$ git-read-tree -m -u <origtree> <yourtree> <targettree></p></div><p>which will do all trivial merge operations for you directly in the
index file, and you can just write the result out with
<code class="literal">git-write-tree</code>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="merging-multiple-trees-2"></a>Merging multiple trees, continued</h2></div></div></div><p>Sadly, many merges aren't trivial. If there are files that have
-been added.moved or removed, or if both branches have modified the
+been added, moved or removed, or if both branches have modified the
same file, you will be left with an index tree that contains "merge
entries" in it. Such an index tree can <span class="emphasis"><em>NOT</em></span> be written out to a tree
object, and you will have to resolve any such merge clashes using
repository, it writes the resulting SHA-1 into the variable <code class="literal">sha1</code>.</p><p>Two things are interesting here:</p><div class="itemizedlist"><ul type="disc"><li>
<code class="literal">get_sha1()</code> returns 0 on _success_. This might surprise some new
Git hackers, but there is a long tradition in UNIX to return different
- negative numbers in case of different errors — and 0 on success.
+ negative numbers in case of different errors—and 0 on success.
</li><li>
the variable <code class="literal">sha1</code> in the function signature of <code class="literal">get_sha1()</code> is <code class="literal">unsigned
char *</code>, but is actually expected to be a pointer to <code class="literal">unsigned
</span></dt><dd>
In <a href="#def_SCM">SCM</a> jargon, "cherry pick" means to choose a subset of
changes out of a series of changes (typically commits) and record them
- as a new series of changes on top of different codebase. In GIT, this is
- performed by "git cherry-pick" command to extract the change introduced
+ as a new series of changes on top of a different codebase. In GIT, this is
+ performed by the "git cherry-pick" command to extract the change introduced
by an existing <a href="#def_commit">commit</a> and to record it based on the tip
of the current <a href="#def_branch">branch</a> as a new commit.
</dd><dt><span class="term">
</span></dt><dd>
The term <a href="#def_pickaxe">pickaxe</a> refers to an option to the diffcore
routines that help select changes that add or delete a given text
- string. With the —pickaxe-all option, it can be used to view the full
+ string. With the <code class="literal">—pickaxe-all</code> option, it can be used to view the full
<a href="#def_changeset">changeset</a> that introduced or removed, say, a
particular line of text. See <a href="git-diff.html" target="_top">git-diff(1)</a>.
</dd><dt><span class="term">
</span></dt><dd>
Pushing a <a href="#def_branch">branch</a> means to get the branch's
<a href="#def_head_ref">head ref</a> from a remote <a href="#def_repository">repository</a>,
- find out if it is an ancestor to the branch's local
- head ref is a direct, and in that case, putting all
+ find out if it is a direct ancestor to the branch's local
+ head ref, and in that case, putting all
objects, which are <a href="#def_reachable">reachable</a> from the local
head ref, and which are missing from the remote
repository, into the remote
it as my origin branch head". And <code class="literal">git push
$URL refs/heads/master:refs/heads/to-upstream</code> means "publish my
master branch head as to-upstream branch at $URL". See also
- <a href="git-push.html" target="_top">git-push(1)</a>
+ <a href="git-push.html" target="_top">git-push(1)</a>.
</dd><dt><span class="term">
<a name="def_repository"></a>repository
</span></dt><dd>
$ cd project</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="managing-branches"></a>Managing branches</h2></div></div></div><div class="literallayout"><p>$ git branch # list all local branches in this repo<br>
$ git checkout test # switch working directory to branch "test"<br>
$ git branch new # create branch "new" starting at current HEAD<br>
-$ git branch -d new # delete branch "new"</p></div><p>Instead of basing new branch on current HEAD (the default), use:</p><div class="literallayout"><p>$ git branch new test # branch named "test"<br>
+$ git branch -d new # delete branch "new"</p></div><p>Instead of basing
a new branch on current HEAD (the default), use:</p><div class="literallayout"><p>$ git branch new test # branch named "test"<br>
$ git branch new v2.6.15 # tag named v2.6.15<br>
$ git branch new HEAD^ # commit before the most recent<br>
$ git branch new HEAD^^ # commit before that<br>
commit. You can find out with this:
-------------------------------------------------
-$ git log --raw --abbrev=40 --pretty=oneline -- filename |
+$ git log --raw --abbrev=40 --pretty=oneline |
grep -B 1 `git hash-object filename`
-------------------------------------------------
-------------------------
On large repositories, git depends on compression to keep the history
-information from taking up to much space on disk or in memory.
+information from taking up too much space on disk or in memory.
This compression is not performed automatically. Therefore you
should occasionally run gitlink:git-gc[1]:
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 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
+you wish, you can remove them with gitlink:git-prune[1] or the `--prune`
option to gitlink:git-gc[1]:
-------------------------------------------------
Reflogs
^^^^^^^
-Say you modify a branch with gitlink:git-reset[1] --hard, and then
+Say you modify a branch with `gitlink:git-reset[1] --hard`, and then
realize that the branch was the only reference you had to that point in
history.
More generally, a branch that is created from a remote branch will pull
by default from that branch. See the descriptions of the
branch.<name>.remote and branch.<name>.merge options in
-gitlink:git-config[1], and the discussion of the --track option in
+gitlink:git-config[1], and the discussion of the `--track` option in
gitlink:git-checkout[1], to learn how to control these defaults.
In addition to saving you keystrokes, "git pull" also helps you by
$ git pull /path/to/other/repository
-------------------------------------------------
-or an ssh url:
+or an ssh URL:
-------------------------------------------------
$ git clone ssh://yourhost/~you/repository
This is the preferred method.
If someone else administers the server, they should tell you what
-directory to put the repository in, and what git:// url it will appear
+directory to put the repository in, and what git:// URL it will appear
at. You can then skip to the section
"<<pushing-changes-to-a-public-repository,Pushing changes to a public
repository>>", below.
gitlink:git-update-server-info[1], and the documentation
link:hooks.html[Hooks used by git].)
-Advertise the url of proj.git. Anybody else should then be able to
-clone or pull from that url, for example with a command line like:
+Advertise the URL of proj.git. Anybody else should then be able to
+clone or pull from that URL, for example with a command line like:
-------------------------------------------------
$ git clone http://yourserver.com/~you/proj.git
a <<fast-forwards,fast forward>>. Normally this is a sign of
something wrong. However, if you are sure you know what you're
doing, you may force git-push to perform the update anyway by
-proceeding the branch name by a plus sign:
+preceding the branch name by a plus sign:
-------------------------------------------------
$ git push ssh://yourserver.com/~you/proj.git +master
$ git branch --track release origin/master
-------------------------------------------------
-These can be easily kept up to date using gitlink:git-pull[1]
+These can be easily kept up to date using gitlink:git-pull[1].
-------------------------------------------------
$ git checkout test && git pull
$ git log linux..branchname | git-shortlog
-------------------------------------------------
-To see whether it has already been merged into the test or release branches
+To see whether it has already been merged into the test or release branches,
use:
-------------------------------------------------
$ git log release..branchname
-------------------------------------------------
-(If this branch has not yet been merged you will see some log entries.
+(If this branch has not yet been merged, you will see some log entries.
If it has been merged, then there will be no output.)
Once a patch completes the great cycle (moving from test to release,
then pulled by Linus, and finally coming back into your local
-"origin/master" branch) the branch for this change is no longer needed.
+"origin/master" branch), the branch for this change is no longer needed.
You detect this when the output from:
-------------------------------------------------
and git will continue applying the rest of the patches.
-At any point you may use the --abort option to abort this process and
+At any point you may use the `--abort` option to abort this process and
return mywork to the state it had before you started the rebase:
-------------------------------------------------
$ gitk origin..mywork &
-------------------------------------------------
-And browse through the list of patches in the mywork branch using gitk,
+and browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
-cherry-pick, and possibly modifying them as you go using commit --amend.
+cherry-pick, and possibly modifying them as you go using `commit --amend`.
The gitlink:git-gui[1] command may also help as it allows you to
individually select diff hunks for inclusion in the index (by
right-clicking on the diff hunk and choosing "Stage Hunk for Commit").
- Git can quickly determine whether two objects are identical or not,
just by comparing names.
-- Since object names are computed the same way in ever repository, the
+- Since object names are computed the same way in every repository, the
same content stored in two repositories will always be stored under
the same name.
- Git can detect errors when it reads an object, by checking that the
"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
- together into a <<def_DAG,directed acyclic graph>> of revisions - each
+ together into a <<def_DAG,directed acyclic graph>> of revisions--each
commit contains the object name of exactly one tree designating the
directory hierarchy at the time of the commit. In addition, a commit
refers to "parent" commit objects that describe the history of how we
example, a "dangling blob" may arise because you did a "git add" of a
file, but then, before you actually committed it and made it part of the
bigger picture, you changed something else in that file and committed
-that *updated* thing - the old state that you added originally ends up
+that *updated* thing--the old state that you added originally ends up
not being pointed to by any commit or tree, so it's now a dangling blob
object.
Generally, dangling objects aren't anything to worry about. They can
even be very useful: if you screw something up, the dangling objects can
be how you recover your old tree (say, you did a rebase, and realized
-that you really didn't want to - you can look at what dangling objects
+that you really didn't want to--you can look at what dangling objects
you have, and decide to reset your head to some old dangling state).
For commits, you can just use:
------------------------------------------------
and they'll be gone. But you should only run "git prune" on a quiescent
-repository - it's kind of like doing a filesystem fsck recovery: you
+repository--it's kind of like doing a filesystem fsck recovery: you
don't want to do that while the filesystem is mounted.
-(The same is true of "git-fsck" itself, btw - but since
+(The same is true of "git-fsck" itself, btw, but since
git-fsck never actually *changes* the repository, it just reports
on what it found, git-fsck itself is never "dangerous" to run.
Running it while somebody is actually changing the repository can cause
------------
High-level operations such as gitlink:git-commit[1],
-gitlink:git-checkout[1] and git-reset[1] work by moving data between the
-working tree, the index, and the object database. Git provides
-low-level operations which perform each of these steps individually.
+gitlink:git-checkout[1] and gitlink:git-reset[1] work by moving data
+between the working tree, the index, and the object database. Git
+provides low-level operations which perform each of these steps
+individually.
Generally, all "git" operations work on the index file. Some operations
work *purely* on the index file (showing the current state of the
$ git write-tree
-------------------------------------------------
-that doesn't come with any options - it will just write out the
+that doesn't come with any options--it will just write out the
current index into the set of tree objects that describe that state,
and it will return the name of the resulting top-level tree. You can
use that tree to re-generate the index at any time by going in the
~~~~~~~~~~~~~~~~~~~~~~~~
You read a "tree" file from the object database, and use that to
-populate (and overwrite - don't do this if your index contains any
+populate (and overwrite--don't do this if your index contains any
unsaved state that you might want to restore later!) your current
index. Normal operation is just
To commit a tree you have instantiated with "git-write-tree", you'd
create a "commit" object that refers to that tree and the history
-behind it - most notably the "parent" commits that preceded it in
+behind it--most notably the "parent" commits that preceded it in
history.
Normally a "commit" has one parent: the previous state of the tree
tree, aka the common tree, and the two "result" trees, aka the branches
you want to merge), you do a "merge" read into the index. This will
complain if it has to throw away your old index contents, so you should
-make sure that you've committed those - in fact you would normally
+make sure that you've committed those--in fact you would normally
always do a merge against your last commit (which should thus match what
you have in your current index anyway).
---------------------------------
Sadly, many merges aren't trivial. If there are files that have
-been added.moved or removed, or if both branches have modified the
+been added, moved or removed, or if both branches have modified the
same file, you will be left with an index tree that contains "merge
entries" in it. Such an index tree can 'NOT' be written out to a tree
object, and you will have to resolve any such merge clashes using
- `get_sha1()` returns 0 on _success_. This might surprise some new
Git hackers, but there is a long tradition in UNIX to return different
- negative numbers in case of different errors -- and 0 on success.
+ negative numbers in case of different errors--and 0 on success.
- the variable `sha1` in the function signature of `get_sha1()` is `unsigned
char \*`, but is actually expected to be a pointer to `unsigned
$ git branch -d new # delete branch "new"
-----------------------------------------------
-Instead of basing new branch on current HEAD (the default), use:
+Instead of basing a new branch on current HEAD (the default), use:
-----------------------------------------------
$ git branch new test # branch named "test"
projects / git.git / commitdiff