--- /dev/null
+GIT v1.5.2.3 Release Notes
+==========================
+
+Fixes since v1.5.2.2
+--------------------
+
+ * Bugfixes
+
+ - Version 2 pack index format was introduced in version 1.5.2
+ to support pack files that has offset that cannot be
+ represented in 32-bit. The runtime code to validate such
+ an index mishandled such an index for an empty pack.
+
+ - Commit walkers (most notably, fetch over http protocol)
+ tried to traverse commit objects contained in trees (aka
+ subproject); they shouldn't.
+
+ - A build option NO_R_TO_GCC_LINKER was not explained in Makefile
+ comment correctly.
+
+ * Documentation Fixes and Updates
+
+ - git-config --regexp was not documented properly.
+
+ - git-repack -a was not documented properly.
+
+ - git-remote -n was not documented properly.
gitlink:git-show[1]::
Show various types of objects.
+gitlink:git-stash[1]::
+ Stash the changes in a dirty working directory away.
+
gitlink:git-status[1]::
Show the working tree status.
+
Common unit suffixes of 'k', 'm', or 'g' are supported.
-core.excludeFile::
+core.excludesfile::
In addition to '.gitignore' (per-directory) and
'.git/info/exclude', git looks into this file for patterns
of files which are not meant to be tracked. See
to happen.</p>\r
<p>With a <tt>-d</tt> or <tt>-D</tt> option, <tt><branchname></tt> will be deleted. You may\r
specify more than one branch for deletion. If the branch currently\r
-has a ref log then the ref log will also be deleted. Use -r together with -d\r
+has a reflog then the reflog will also be deleted. Use -r together with -d\r
to delete remote-tracking branches.</p>\r
</div>\r
<h2>OPTIONS</h2>\r
</dt>\r
<dd>\r
<p>\r
- Create the branch's ref log. This activates recording of\r
- all changes to made the branch ref, enabling use of date\r
+ Create the branch's reflog. This activates recording of\r
+ all changes made to the branch ref, enabling use of date\r
+ based sha1 expressions such as "<branchname>@{yesterday}".\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 16-Jun-2007 09:48:55 UTC\r
+Last updated 03-Jul-2007 07:03:39 UTC\r
</div>\r
</div>\r
</body>\r
With a `-d` or `-D` option, `<branchname>` will be deleted. You may
specify more than one branch for deletion. If the branch currently
-has a ref log then the ref log will also be deleted. Use -r together with -d
+has a reflog then the reflog will also be deleted. Use -r together with -d
to delete remote-tracking branches.
Delete a branch irrespective of its index status.
-l::
- Create the branch's ref log. This activates recording of
- all changes to made the branch ref, enabling use of date
- based sha1 expressions such as "<branchname>@{yesterday}".
+ Create the branch's reflog. This activates recording of
+ all changes made to the branch ref, enabling use of date
+ based sha1 expressions such as "<branchname>@\{yesterday}".
-f::
Force the creation of a new branch even if it means deleting
</dt>\r
<dd>\r
<p>\r
- Create the new branch's ref log. This activates recording of\r
- all changes to made the branch ref, enabling use of date\r
+ Create the new branch's reflog. This activates recording of\r
+ all changes made to the branch ref, enabling use of date\r
+ based sha1 expressions such as "<branchname>@{yesterday}".\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 16-Jun-2007 09:48:56 UTC\r
+Last updated 03-Jul-2007 07:03:39 UTC\r
</div>\r
</div>\r
</body>\r
configuration variable.
-l::
- Create the new branch's ref log. This activates recording of
- all changes to made the branch ref, enabling use of date
- based sha1 expressions such as "<branchname>@{yesterday}".
+ Create the new branch's reflog. This activates recording of
+ all changes made to the branch ref, enabling use of date
+ based sha1 expressions such as "<branchname>@\{yesterday}".
-m::
If you have local modifications to one or more files that
<p>Common unit suffixes of <em>k</em>, <em>m</em>, or <em>g</em> are supported.</p>\r
</dd>\r
<dt>\r
-core.excludeFile\r
+core.excludesfile\r
</dt>\r
<dd>\r
<p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 02-Jul-2007 00:16:57 UTC\r
+Last updated 03-Jul-2007 07:03:40 UTC\r
</div>\r
</div>\r
</body>\r
<h2>CONFIGURATION</h2>\r
<div class="sectionbody">\r
<p>You can specify extra mail header lines to be added to each\r
-message in the repository configuration. Also you can specify\r
-the default suffix different from the built-in one:</p>\r
+message in the repository configuration. You can also specify\r
+new defaults for the subject prefix and file suffix.</p>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>[format]\r
headers = "Organization: git-foo\n"\r
+ subjectprefix = CHANGE\r
suffix = .txt</tt></pre>\r
</div></div>\r
</div>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 16-Jun-2007 09:49:06 UTC\r
+Last updated 03-Jul-2007 07:03:40 UTC\r
</div>\r
</div>\r
</body>\r
CONFIGURATION
-------------
You can specify extra mail header lines to be added to each
-message in the repository configuration. Also you can specify
-the default suffix different from the built-in one:
+message in the repository configuration. You can also specify
+new defaults for the subject prefix and file suffix.
------------
[format]
headers = "Organization: git-foo\n"
+ subjectprefix = CHANGE
suffix = .txt
------------
<div class="sectionbody">\r
<div class="verseblock">\r
<div class="content"><em>git-fsck</em> [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]\r
- [--full] [--strict] [--verbose] [<object>*]</div></div>\r
+ [--full] [--strict] [--verbose] [--lost-found] [<object>*]</div></div>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
Be chatty.\r
</p>\r
</dd>\r
+<dt>\r
+--lost-found\r
+</dt>\r
+<dd>\r
+<p>\r
+ Write dangling refs into .git/commit/ or .git/other/, depending\r
+ on type.\r
+</p>\r
+</dd>\r
</dl>\r
<p>It tests SHA1 and general object sanity, and it does full tracking of\r
the resulting reachability and everything else. It prints out any\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 16-Jun-2007 09:49:06 UTC\r
+Last updated 03-Jul-2007 07:03:41 UTC\r
</div>\r
</div>\r
</body>\r
--------
[verse]
'git-fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
- [--full] [--strict] [--verbose] [<object>*]
+ [--full] [--strict] [--verbose] [--lost-found] [<object>*]
DESCRIPTION
-----------
--verbose::
Be chatty.
+--lost-found::
+ Write dangling refs into .git/commit/ or .git/other/, depending
+ on type.
+
It tests SHA1 and general object sanity, and it does full tracking of
the resulting reachability and everything else. It prints out any
corruption it finds (missing or bad objects), and if you use the
</div>\r
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
-<p><em>git-init-db</em> [--template=<template_directory>] [--shared[=<permissions>]]</p>\r
+<p><em>git-init-db</em> [-q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]]</p>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 16-Jun-2007 09:49:08 UTC\r
+Last updated 03-Jul-2007 07:03:42 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
-'git-init-db' [--template=<template_directory>] [--shared[=<permissions>]]
+'git-init-db' [-
q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]]
DESCRIPTION
</div>\r
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
-<p><em>git-init</em> [--template=<template_directory>] [--shared[=<permissions>]]</p>\r
+<p><em>git-init</em> [-q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]]</p>\r
</div>\r
<h2>OPTIONS</h2>\r
<div class="sectionbody">\r
<dl>\r
<dt>\r
+-q, --quiet\r
+</dt>\r
+<dd>\r
+<p>\r
+Only print error and warning messages, all other output will be suppressed.\r
+</p>\r
+</dd>\r
+<dt>\r
--template=<template_directory>\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 16-Jun-2007 09:49:09 UTC\r
+Last updated 03-Jul-2007 07:03:43 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
-'git-init' [--template=<template_directory>] [--shared[=<permissions>]]
+'git-init' [-
q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]]
OPTIONS
--
+-q, \--quiet::
+
+Only print error and warning messages, all other output will be suppressed.
+
--template=<template_directory>::
Provide the directory from which templates will be used. The default template
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
+<p>THIS COMMAND IS DEPRECATED.</p>\r
<p>Duplicates another git repository on a local system.</p>\r
</div>\r
<h2>OPTIONS</h2>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 16-Jun-2007 09:49:09 UTC\r
+Last updated 03-Jul-2007 07:03:43 UTC\r
</div>\r
</div>\r
</body>\r
DESCRIPTION
-----------
+THIS COMMAND IS DEPRECATED.
+
Duplicates another git repository on a local system.
OPTIONS
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
<div class="verseblock">\r
-<div class="content"><em>git-rebase</em> [-v] [--merge] [-C<n>] [--onto <newbase>] <upstream> [<branch>]\r
+<div class="content"><em>git-rebase</em> [-i | --interactive] [-v | --verbose] [--merge] [-C<n>]\r
+ [-p | --preserve-merges] [--onto <newbase>] <upstream> [<branch>]\r
<em>git-rebase</em> --continue | --skip | --abort</div></div>\r
</div>\r
<h2>DESCRIPTION</h2>\r
ever ignored.\r
</p>\r
</dd>\r
+<dt>\r
+-i, --interactive\r
+</dt>\r
+<dd>\r
+<p>\r
+ Make a list of the commits which are about to be rebased. Let the\r
+ user edit that list before rebasing.\r
+</p>\r
+</dd>\r
+<dt>\r
+-p, --preserve-merges\r
+</dt>\r
+<dd>\r
+<p>\r
+ Instead of ignoring merges, try to recreate them. This option\r
+ only works in interactive mode.\r
+</p>\r
+</dd>\r
</dl>\r
</div>\r
<h2>MERGE STRATEGIES</h2>\r
<p>You must be in the top directory of your project to start (or continue)\r
a rebase. Upon completion, <branch> will be the current branch.</p>\r
</div>\r
-<h2>Author</h2>\r
+<h2>INTERACTIVE MODE</h2>\r
+<div class="sectionbody">\r
+<p>Rebasing interactively means that you have a chance to edit the commits\r
+which are rebased. You can reorder the commits, and you can\r
+remove them (weeding out bad or otherwise unwanted patches).</p>\r
+<p>The interactive mode is meant for this type of workflow:</p>\r
+<ol>\r
+<li>\r
+<p>\r
+have a wonderful idea\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+hack on the code\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+prepare a series for submission\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+submit\r
+</p>\r
+</li>\r
+</ol>\r
+<p>where point 2. consists of several instances of</p>\r
+<ol class="olist2">\r
+<li>\r
+<p>\r
+regular use\r
+</p>\r
+<ol>\r
+<li>\r
+<p>\r
+finish something worthy of a commit\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+commit\r
+</p>\r
+</li>\r
+</ol>\r
+</li>\r
+<li>\r
+<p>\r
+independent fixup\r
+</p>\r
+<ol>\r
+<li>\r
+<p>\r
+realize that something does not work\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+fix that\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
+commit it\r
+</p>\r
+</li>\r
+</ol>\r
+</li>\r
+</ol>\r
+<p>Sometimes the thing fixed in b.2. cannot be amended to the not-quite\r
+perfect commit it fixes, because that commit is buried deeply in a\r
+patch series. That is exactly what interactive rebase is for: use it\r
+after plenty of "a"s and "b"s, by rearranging and editing\r
+commits, and squashing multiple commits into one.</p>\r
+<p>Start it with the last commit you want to retain as-is:</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>git rebase -i <after-this-commit></tt></pre>\r
+</div></div>\r
+<p>An editor will be fired up with all the commits in your current branch\r
+(ignoring merge commits), which come after the given commit. You can\r
+reorder the commits in this list to your heart's content, and you can\r
+remove them. The list looks more or less like this:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>pick deadbee The oneline of this commit\r
+pick fa1afe1 The oneline of the next commit\r
+...</tt></pre>\r
+</div></div>\r
+<p>The oneline descriptions are purely for your pleasure; <tt>git-rebase</tt> will\r
+not look at them but at the commit names ("deadbee" and "fa1afe1" in this\r
+example), so do not delete or edit the names.</p>\r
+<p>By replacing the command "pick" with the command "edit", you can tell\r
+<tt>git-rebase</tt> to stop after applying that commit, so that you can edit\r
+the files and/or the commit message, amend the commit, and continue\r
+rebasing.</p>\r
+<p>If you want to fold two or more commits into one, replace the command\r
+"pick" with "squash" for the second and subsequent commit. If the\r
+commits had different authors, it will attribute the squashed commit to\r
+the author of the last commit.</p>\r
+<p>In both cases, or when a "pick" does not succeed (because of merge\r
+errors), the loop will stop to let you fix things, and you can continue\r
+the loop with <tt>git rebase --continue</tt>.</p>\r
+<p>For example, if you want to reorder the last 5 commits, such that what\r
+was HEAD~4 becomes the new HEAD. To achieve that, you would call\r
+<tt>git-rebase</tt> like this:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git rebase -i HEAD~5</tt></pre>\r
+</div></div>\r
+<p>And move the first patch to the end of the list.</p>\r
+<p>You might want to preserve merges, if you have a history like this:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt> X\r
+ \\r
+ A---M---B\r
+ /\r
+---o---O---P---Q</tt></pre>\r
+</div></div>\r
+<p>Suppose you want to rebase the side branch starting at "A" to "Q". Make\r
+sure that the current HEAD is "B", and call</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git rebase -i -p --onto Q O</tt></pre>\r
+</div></div>\r
+</div>\r
+<h2>Authors</h2>\r
<div class="sectionbody">\r
-<p>Written by Junio C Hamano <junkio@cox.net></p>\r
+<p>Written by Junio C Hamano <junkio@cox.net> and\r
+Johannes E. Schindelin <johannes.schindelin@gmx.de></p>\r
</div>\r
<h2>Documentation</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 16-Jun-2007 09:49:16 UTC\r
+Last updated 03-Jul-2007 07:03:43 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
[verse]
-'git-rebase' [-v] [--merge] [-C<n>] [--onto <newbase>] <upstream> [<branch>]
+'git-rebase' [-i | --interactive] [-v | --verbose] [--merge] [-C<n>]
+ [-p | --preserve-merges] [--onto <newbase>] <upstream> [<branch>]
'git-rebase' --continue | --skip | --abort
DESCRIPTION
context exist they all must match. By default no context is
ever ignored.
+-i, \--interactive::
+ Make a list of the commits which are about to be rebased. Let the
+ user edit that list before rebasing.
+
+-p, \--preserve-merges::
+ Instead of ignoring merges, try to recreate them. This option
+ only works in interactive mode.
+
include::merge-strategies.txt[]
NOTES
You must be in the top directory of your project to start (or continue)
a rebase. Upon completion, <branch> will be the current branch.
-Author
+INTERACTIVE MODE
+----------------
+
+Rebasing interactively means that you have a chance to edit the commits
+which are rebased. You can reorder the commits, and you can
+remove them (weeding out bad or otherwise unwanted patches).
+
+The interactive mode is meant for this type of workflow:
+
+1. have a wonderful idea
+2. hack on the code
+3. prepare a series for submission
+4. submit
+
+where point 2. consists of several instances of
+
+a. regular use
+ 1. finish something worthy of a commit
+ 2. commit
+b. independent fixup
+ 1. realize that something does not work
+ 2. fix that
+ 3. commit it
+
+Sometimes the thing fixed in b.2. cannot be amended to the not-quite
+perfect commit it fixes, because that commit is buried deeply in a
+patch series. That is exactly what interactive rebase is for: use it
+after plenty of "a"s and "b"s, by rearranging and editing
+commits, and squashing multiple commits into one.
+
+Start it with the last commit you want to retain as-is:
+
+ git rebase -i <after-this-commit>
+
+An editor will be fired up with all the commits in your current branch
+(ignoring merge commits), which come after the given commit. You can
+reorder the commits in this list to your heart's content, and you can
+remove them. The list looks more or less like this:
+
+-------------------------------------------
+pick deadbee The oneline of this commit
+pick fa1afe1 The oneline of the next commit
+...
+-------------------------------------------
+
+The oneline descriptions are purely for your pleasure; `git-rebase` will
+not look at them but at the commit names ("deadbee" and "fa1afe1" in this
+example), so do not delete or edit the names.
+
+By replacing the command "pick" with the command "edit", you can tell
+`git-rebase` to stop after applying that commit, so that you can edit
+the files and/or the commit message, amend the commit, and continue
+rebasing.
+
+If you want to fold two or more commits into one, replace the command
+"pick" with "squash" for the second and subsequent commit. If the
+commits had different authors, it will attribute the squashed commit to
+the author of the last commit.
+
+In both cases, or when a "pick" does not succeed (because of merge
+errors), the loop will stop to let you fix things, and you can continue
+the loop with `git rebase --continue`.
+
+For example, if you want to reorder the last 5 commits, such that what
+was HEAD~4 becomes the new HEAD. To achieve that, you would call
+`git-rebase` like this:
+
+----------------------
+$ git rebase -i HEAD~5
+----------------------
+
+And move the first patch to the end of the list.
+
+You might want to preserve merges, if you have a history like this:
+
+------------------
+ X
+ \
+ A---M---B
+ /
+---o---O---P---Q
+------------------
+
+Suppose you want to rebase the side branch starting at "A" to "Q". Make
+sure that the current HEAD is "B", and call
+
+-----------------------------
+$ git rebase -i -p --onto Q O
+-----------------------------
+
+Authors
------
-Written by Junio C Hamano <junkio@cox.net>
+Written by Junio C Hamano <junkio@cox.net> and
+Johannes E. Schindelin <johannes.schindelin@gmx.de>
Documentation
--------------
<p>The refname value is relative to $GIT_DIR; e.g. for the master\r
head this is "refs/heads/master". The two sha1 values before\r
each refname are the object names for the refname before and after\r
+the update. Refs to be created will have sha1-old equal to 0{40},\r
+while refs to be deleted will have sha1-new equal to 0{40}, otherwise\r
sha1-old and sha1-new should be valid objects in the repository.</p>\r
<p>This hook is called before any refname is updated and before any\r
fast-forward checks are performed.</p>\r
head this is "refs/heads/master". The two sha1 arguments are\r
the object names for the refname before and after the update.\r
Note that the hook is called before the refname is updated,\r
+so either sha1-old is 0{40} (meaning there is no such ref yet),\r
or it should match what is recorded in refname.</p>\r
<p>The hook should exit with non-zero status if it wants to disallow\r
updating the named ref. Otherwise it should exit with zero.</p>\r
head this is "refs/heads/master". The two sha1 values before\r
each refname are the object names for the refname before and after\r
the update. Refs that were created will have sha1-old equal to\r
+0{40}, while refs that were deleted will have sha1-new equal to\r
+0{40}, otherwise sha1-old and sha1-new should be valid objects in\r
the repository.</p>\r
<p>Using this hook, it is easy to generate mails describing the updates\r
to the repository. This example script sends one mail message per\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 16-Jun-2007 09:49:17 UTC\r
+Last updated 03-Jul-2007 07:03:43 UTC\r
</div>\r
</div>\r
</body>\r
The refname value is relative to $GIT_DIR; e.g. for the master
head this is "refs/heads/master". The two sha1 values before
each refname are the object names for the refname before and after
-the update. Refs to be created will have sha1-old equal to 0{40},
-while refs to be deleted will have sha1-new equal to 0{40}, otherwise
+the update. Refs to be created will have sha1-old equal to 0\{40},
+while refs to be deleted will have sha1-new equal to 0\{40}, otherwise
sha1-old and sha1-new should be valid objects in the repository.
This hook is called before any refname is updated and before any
head this is "refs/heads/master". The two sha1 arguments are
the object names for the refname before and after the update.
Note that the hook is called before the refname is updated,
-so either sha1-old is 0{40} (meaning there is no such ref yet),
+so either sha1-old is 0\{40} (meaning there is no such ref yet),
or it should match what is recorded in refname.
The hook should exit with non-zero status if it wants to disallow
head this is "refs/heads/master". The two sha1 values before
each refname are the object names for the refname before and after
the update. Refs that were created will have sha1-old equal to
-0{40}, while refs that were deleted will have sha1-new equal to
-0{40}, otherwise sha1-old and sha1-new should be valid objects in
+0\{40}, while refs that were deleted will have sha1-new equal to
+0\{40}, otherwise sha1-old and sha1-new should be valid objects in
the repository.
Using this hook, it is easy to generate mails describing the updates
nor <em>commit1…commit2</em> notations cannot be used).<br />\r
With <em>--pretty</em> format other than oneline (for obvious reasons),\r
this causes the output to have two extra lines of information\r
+taken from the reflog. By default, <em>commit@{Nth}</em> notation is\r
used in the output. When the starting commit is specified as\r
instead. Under <em>--pretty=oneline</em>, the commit message is\r
prefixed with this information on the same line.\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 21-Jun-2007 00:35:00 UTC\r
+Last updated 03-Jul-2007 07:03:44 UTC\r
</div>\r
</div>\r
</body>\r
+
With '\--pretty' format other than oneline (for obvious reasons),
this causes the output to have two extra lines of information
-taken from the reflog. By default, 'commit@{Nth}' notation is
+taken from the reflog. By default, 'commit@\{Nth}' notation is
used in the output. When the starting commit is specified as
-'commit@{now}', output also uses 'commit@{timestamp}' notation
+'commit@{now}', output also uses 'commit@\{timestamp}' notation
instead. Under '\--pretty=oneline', the commit message is
prefixed with this information on the same line.
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
+<p>THIS COMMAND IS DEPRECATED.</p>\r
<p>Pulls from a remote repository over ssh connection, invoking\r
git-ssh-upload on the other end. It functions identically to\r
git-ssh-upload, aside from which end you run it on.</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 16-Jun-2007 09:49:23 UTC\r
+Last updated 03-Jul-2007 07:03:45 UTC\r
</div>\r
</div>\r
</body>\r
DESCRIPTION
-----------
+THIS COMMAND IS DEPRECATED.
+
Pulls from a remote repository over ssh connection, invoking
git-ssh-upload on the other end. It functions identically to
git-ssh-upload, aside from which end you run it on.
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
+<p>THIS COMMAND IS DEPRECATED.</p>\r
<p>Pushes from a remote repository over ssh connection, invoking\r
git-ssh-fetch on the other end. It functions identically to\r
git-ssh-fetch, aside from which end you run it on.</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 16-Jun-2007 09:49:23 UTC\r
+Last updated 03-Jul-2007 07:03:45 UTC\r
</div>\r
</div>\r
</body>\r
DESCRIPTION
-----------
+THIS COMMAND IS DEPRECATED.
+
Pushes from a remote repository over ssh connection, invoking
git-ssh-fetch on the other end. It functions identically to
git-ssh-fetch, aside from which end you run it on.
--- /dev/null
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"\r
+ "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">\r
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">\r
+<head>\r
+<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />\r
+<meta name="generator" content="AsciiDoc 7.0.2" />\r
+<style type="text/css">\r
+/* Debug borders */\r
+p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {\r
+/*\r
+ border: 1px solid red;\r
+*/\r
+}\r
+\r
+body {\r
+ margin: 1em 5% 1em 5%;\r
+}\r
+\r
+a { color: blue; }\r
+a:visited { color: fuchsia; }\r
+\r
+em {\r
+ font-style: italic;\r
+}\r
+\r
+strong {\r
+ font-weight: bold;\r
+}\r
+\r
+tt {\r
+ color: navy;\r
+}\r
+\r
+h1, h2, h3, h4, h5, h6 {\r
+ color: #527bbd;\r
+ font-family: sans-serif;\r
+ margin-top: 1.2em;\r
+ margin-bottom: 0.5em;\r
+ line-height: 1.3;\r
+}\r
+\r
+h1 {\r
+ border-bottom: 2px solid silver;\r
+}\r
+h2 {\r
+ border-bottom: 2px solid silver;\r
+ padding-top: 0.5em;\r
+}\r
+\r
+div.sectionbody {\r
+ font-family: serif;\r
+ margin-left: 0;\r
+}\r
+\r
+hr {\r
+ border: 1px solid silver;\r
+}\r
+\r
+p {\r
+ margin-top: 0.5em;\r
+ margin-bottom: 0.5em;\r
+}\r
+\r
+pre {\r
+ padding: 0;\r
+ margin: 0;\r
+}\r
+\r
+span#author {\r
+ color: #527bbd;\r
+ font-family: sans-serif;\r
+ font-weight: bold;\r
+ font-size: 1.2em;\r
+}\r
+span#email {\r
+}\r
+span#revision {\r
+ font-family: sans-serif;\r
+}\r
+\r
+div#footer {\r
+ font-family: sans-serif;\r
+ font-size: small;\r
+ border-top: 2px solid silver;\r
+ padding-top: 0.5em;\r
+ margin-top: 4.0em;\r
+}\r
+div#footer-text {\r
+ float: left;\r
+ padding-bottom: 0.5em;\r
+}\r
+div#footer-badges {\r
+ float: right;\r
+ padding-bottom: 0.5em;\r
+}\r
+\r
+div#preamble,\r
+div.tableblock, div.imageblock, div.exampleblock, div.verseblock,\r
+div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,\r
+div.admonitionblock {\r
+ margin-right: 10%;\r
+ margin-top: 1.5em;\r
+ margin-bottom: 1.5em;\r
+}\r
+div.admonitionblock {\r
+ margin-top: 2.5em;\r
+ margin-bottom: 2.5em;\r
+}\r
+\r
+div.content { /* Block element content. */\r
+ padding: 0;\r
+}\r
+\r
+/* Block element titles. */\r
+div.title, caption.title {\r
+ font-family: sans-serif;\r
+ font-weight: bold;\r
+ text-align: left;\r
+ margin-top: 1.0em;\r
+ margin-bottom: 0.5em;\r
+}\r
+div.title + * {\r
+ margin-top: 0;\r
+}\r
+\r
+td div.title:first-child {\r
+ margin-top: 0.0em;\r
+}\r
+div.content div.title:first-child {\r
+ margin-top: 0.0em;\r
+}\r
+div.content + div.title {\r
+ margin-top: 0.0em;\r
+}\r
+\r
+div.sidebarblock > div.content {\r
+ background: #ffffee;\r
+ border: 1px solid silver;\r
+ padding: 0.5em;\r
+}\r
+\r
+div.listingblock > div.content {\r
+ border: 1px solid silver;\r
+ background: #f4f4f4;\r
+ padding: 0.5em;\r
+}\r
+\r
+div.quoteblock > div.content {\r
+ padding-left: 2.0em;\r
+}\r
+div.quoteblock .attribution {\r
+ text-align: right;\r
+}\r
+\r
+div.admonitionblock .icon {\r
+ vertical-align: top;\r
+ font-size: 1.1em;\r
+ font-weight: bold;\r
+ text-decoration: underline;\r
+ color: #527bbd;\r
+ padding-right: 0.5em;\r
+}\r
+div.admonitionblock td.content {\r
+ padding-left: 0.5em;\r
+ border-left: 2px solid silver;\r
+}\r
+\r
+div.exampleblock > div.content {\r
+ border-left: 2px solid silver;\r
+ padding: 0.5em;\r
+}\r
+\r
+div.verseblock div.content {\r
+ white-space: pre;\r
+}\r
+\r
+div.imageblock div.content { padding-left: 0; }\r
+div.imageblock img { border: 1px solid silver; }\r
+span.image img { border-style: none; }\r
+\r
+dl {\r
+ margin-top: 0.8em;\r
+ margin-bottom: 0.8em;\r
+}\r
+dt {\r
+ margin-top: 0.5em;\r
+ margin-bottom: 0;\r
+ font-style: italic;\r
+}\r
+dd > *:first-child {\r
+ margin-top: 0;\r
+}\r
+\r
+ul, ol {\r
+ list-style-position: outside;\r
+}\r
+ol.olist2 {\r
+ list-style-type: lower-alpha;\r
+}\r
+\r
+div.tableblock > table {\r
+ border-color: #527bbd;\r
+ border-width: 3px;\r
+}\r
+thead {\r
+ font-family: sans-serif;\r
+ font-weight: bold;\r
+}\r
+tfoot {\r
+ font-weight: bold;\r
+}\r
+\r
+div.hlist {\r
+ margin-top: 0.8em;\r
+ margin-bottom: 0.8em;\r
+}\r
+td.hlist1 {\r
+ vertical-align: top;\r
+ font-style: italic;\r
+ padding-right: 0.8em;\r
+}\r
+td.hlist2 {\r
+ vertical-align: top;\r
+}\r
+\r
+@media print {\r
+ div#footer-badges { display: none; }\r
+}\r
+include::./stylesheets/xhtml11-manpage.css[]\r
+/* Workarounds for IE6's broken and incomplete CSS2. */\r
+\r
+div.sidebar-content {\r
+ background: #ffffee;\r
+ border: 1px solid silver;\r
+ padding: 0.5em;\r
+}\r
+div.sidebar-title, div.image-title {\r
+ font-family: sans-serif;\r
+ font-weight: bold;\r
+ margin-top: 0.0em;\r
+ margin-bottom: 0.5em;\r
+}\r
+\r
+div.listingblock div.content {\r
+ border: 1px solid silver;\r
+ background: #f4f4f4;\r
+ padding: 0.5em;\r
+}\r
+\r
+div.quoteblock-content {\r
+ padding-left: 2.0em;\r
+}\r
+\r
+div.exampleblock-content {\r
+ border-left: 2px solid silver;\r
+ padding-left: 0.5em;\r
+}\r
+</style>\r
+<title>git-stash(1)</title>\r
+</head>\r
+<body>\r
+<div id="header">\r
+<h1>\r
+git-stash(1) Manual Page\r
+</h1>\r
+<h2>NAME</h2>\r
+<div class="sectionbody">\r
+<p>git-stash -\r
+ Stash the changes in a dirty working directory away\r
+</p>\r
+</div>\r
+</div>\r
+<h2>SYNOPSIS</h2>\r
+<div class="sectionbody">\r
+<div class="verseblock">\r
+<div class="content"><em>git-stash</em> (save | list | show [<stash>] | apply [<stash>] | clear)</div></div>\r
+</div>\r
+<h2>DESCRIPTION</h2>\r
+<div class="sectionbody">\r
+<p>Use <em>git-stash</em> when you want to record the current state of the\r
+working directory and the index, but want to go back to a clean\r
+working directory. The command saves your local modifications away\r
+and reverts the working directory to match the <tt>HEAD</tt> commit.</p>\r
+<p>The modifications stashed away by this command can be listed with\r
+<tt>git-stash list</tt>, inspected with <tt>git-stash show</tt>, and restored\r
+(potentially on top of a different commit) with <tt>git-stash apply</tt>.\r
+Calling git-stash without any arguments is equivalent to <tt>git-stash\r
+save</tt>.</p>\r
+<p>The latest stash you created is stored in <tt>$GIT_DIR/refs/stash</tt>; older\r
+stashes are found in the reflog of this reference and can be named using\r
+the usual reflog syntax (e.g. <tt>stash@{1}</tt> is the most recently\r
+created stash, <tt>stash@{2}</tt> is the one before it, <tt>stash@{2.hours.ago}</tt>\r
+is also possible).</p>\r
+</div>\r
+<h2>OPTIONS</h2>\r
+<div class="sectionbody">\r
+<dl>\r
+<dt>\r
+save\r
+</dt>\r
+<dd>\r
+<p>\r
+ Save your local modifications to a new <em>stash</em>, and run <tt>git-reset\r
+ --hard</tt> to revert them. This is the default action when no\r
+ subcommand is given.\r
+</p>\r
+</dd>\r
+<dt>\r
+list\r
+</dt>\r
+<dd>\r
+<p>\r
+ List the stashes that you currently have. Each <em>stash</em> is listed\r
+ with its name (e.g. <tt>stash@{0}</tt> is the latest stash, `stash@{1} is\r
+ the one before, etc.), the name of the branch that was current when the\r
+ stash was made, and a short description of the commit the stash was\r
+ based on.\r
+</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>stash@{0}: submit: 6ebd0e2... Add git-stash\r
+stash@{1}: master: 9cc0589... Merge branch 'master' of gfi</tt></pre>\r
+</div></div>\r
+</dd>\r
+<dt>\r
+show [<stash>]\r
+</dt>\r
+<dd>\r
+<p>\r
+ Show the changes recorded in the stash as a diff between the 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
+ -p stash@{2}</tt> to view the second most recent stash in patch form).\r
+</p>\r
+</dd>\r
+<dt>\r
+apply [<stash>]\r
+</dt>\r
+<dd>\r
+<p>\r
+ Restore the changes recorded in the stash on top of the current\r
+ working tree state. When no <tt><stash></tt> is given, applies the latest\r
+ one. The working directory must match the index.\r
+</p>\r
+<p>This operation can fail with conflicts; you need to resolve them\r
+by hand in the working tree.</p>\r
+</dd>\r
+<dt>\r
+clear\r
+</dt>\r
+<dd>\r
+<p>\r
+ Remove all the stashed states. Note that those states will then\r
+ be subject to pruning, and may be difficult or impossible to recover.\r
+</p>\r
+</dd>\r
+</dl>\r
+</div>\r
+<h2>DISCUSSION</h2>\r
+<div class="sectionbody">\r
+<p>A stash is represented as a commit whose tree records the state of the\r
+working directory, and its first parent is the commit at <tt>HEAD</tt> when\r
+the stash was created. The tree of the second parent records the\r
+state of the index when the stash is made, and it is made a child of\r
+the <tt>HEAD</tt> commit. The ancestry graph looks like this:</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt> .----W\r
+ / /\r
+...--H----I</tt></pre>\r
+</div></div>\r
+<p>where <tt>H</tt> is the <tt>HEAD</tt> commit, <tt>I</tt> is a commit that records the state\r
+of the index, and <tt>W</tt> is a commit that records the state of the working\r
+tree.</p>\r
+</div>\r
+<h2>EXAMPLES</h2>\r
+<div class="sectionbody">\r
+<dl>\r
+<dt>\r
+Pulling into a dirty tree\r
+</dt>\r
+<dd>\r
+<p>\r
+When you are in the middle of something, you learn that there are\r
+upstream changes that are possibly relevant to what you are\r
+doing. When your local changes do not conflict with the changes in\r
+the upstream, a simple <tt>git pull</tt> will let you move forward.\r
+</p>\r
+<p>However, there are cases in which your local changes do conflict with\r
+the upstream changes, and <tt>git pull</tt> refuses to overwrite your\r
+changes. In such a case, you can stash your changes away,\r
+perform a pull, and then unstash, like this:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git pull\r
+...\r
+file foobar not up to date, cannot merge.\r
+$ git stash\r
+$ git pull\r
+$ git stash apply</tt></pre>\r
+</div></div>\r
+</dd>\r
+<dt>\r
+Interrupted workflow\r
+</dt>\r
+<dd>\r
+<p>\r
+When you are in the middle of something, your boss comes in and\r
+demands that you fix something immediately. Traditionally, you would\r
+make a commit to a temporary branch to store your changes away, and\r
+return to your original branch to make the emergency fix, like this:\r
+</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>... hack hack hack ...\r
+$ git checkout -b my_wip\r
+$ git commit -a -m "WIP"\r
+$ git checkout master\r
+$ edit emergency fix\r
+$ git commit -a -m "Fix in a hurry"\r
+$ git checkout my_wip\r
+$ git reset --soft HEAD^\r
+... continue hacking ...</tt></pre>\r
+</div></div>\r
+<p>You can use <tt>git-stash</tt> to simplify the above, like this:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>... hack hack hack ...\r
+$ git stash\r
+$ edit emergency fix\r
+$ git commit -a -m "Fix in a hurry"\r
+$ git stash apply\r
+... continue hacking ...</tt></pre>\r
+</div></div>\r
+</dd>\r
+</dl>\r
+</div>\r
+<h2>SEE ALSO</h2>\r
+<div class="sectionbody">\r
+<p><a href="git-checkout.html">git-checkout(1)</a>,\r
+<a href="git-commit.html">git-commit(1)</a>,\r
+<a href="git-reflog.html">git-reflog(1)</a>,\r
+<a href="git-reset.html">git-reset(1)</a></p>\r
+</div>\r
+<h2>AUTHOR</h2>\r
+<div class="sectionbody">\r
+<p>Written by Nanako Shiraishi <nanako3@bluebottle.com></p>\r
+</div>\r
+<h2>GIT</h2>\r
+<div class="sectionbody">\r
+<p>Part of the <a href="git.html">git(7)</a> suite</p>\r
+</div>\r
+<div id="footer">\r
+<div id="footer-text">\r
+Last updated 03-Jul-2007 07:03:46 UTC\r
+</div>\r
+</div>\r
+</body>\r
+</html>\r
--- /dev/null
+git-stash(1)
+============
+
+NAME
+----
+git-stash - Stash the changes in a dirty working directory away
+
+SYNOPSIS
+--------
+[verse]
+'git-stash' (save | list | show [<stash>] | apply [<stash>] | clear)
+
+DESCRIPTION
+-----------
+
+Use 'git-stash' when you want to record the current state of the
+working directory and the index, but want to go back to a clean
+working directory. The command saves your local modifications away
+and reverts the working directory to match the `HEAD` commit.
+
+The modifications stashed away by this command can be listed with
+`git-stash list`, inspected with `git-stash show`, and restored
+(potentially on top of a different commit) with `git-stash apply`.
+Calling git-stash without any arguments is equivalent to `git-stash
+save`.
+
+The latest stash you created is stored in `$GIT_DIR/refs/stash`; older
+stashes are found in the reflog of this reference and can be named using
+the usual reflog syntax (e.g. `stash@\{1}` is the most recently
+created stash, `stash@\{2}` is the one before it, `stash@\{2.hours.ago}`
+is also possible).
+
+OPTIONS
+-------
+
+save::
+
+ Save your local modifications to a new 'stash', and run `git-reset
+ --hard` to revert them. This is the default action when no
+ subcommand is given.
+
+list::
+
+ List the stashes that you currently have. Each 'stash' is listed
+ with its name (e.g. `stash@\{0}` is the latest stash, `stash@\{1} is
+ the one before, etc.), the name of the branch that was current when the
+ stash was made, and a short description of the commit the stash was
+ based on.
++
+----------------------------------------------------------------
+stash@{0}: submit: 6ebd0e2... Add git-stash
+stash@{1}: master: 9cc0589... Merge branch 'master' of gfi
+----------------------------------------------------------------
+
+show [<stash>]::
+
+ Show the changes recorded in the stash as a diff between the 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
+ -p stash@\{2}` to view the second most recent stash in patch form).
+
+apply [<stash>]::
+
+ Restore the changes recorded in the stash on top of the current
+ working tree state. When no `<stash>` is given, applies the latest
+ one. The working directory must match the index.
++
+This operation can fail with conflicts; you need to resolve them
+by hand in the working tree.
+
+clear::
+ Remove all the stashed states. Note that those states will then
+ be subject to pruning, and may be difficult or impossible to recover.
+
+
+DISCUSSION
+----------
+
+A stash is represented as a commit whose tree records the state of the
+working directory, and its first parent is the commit at `HEAD` when
+the stash was created. The tree of the second parent records the
+state of the index when the stash is made, and it is made a child of
+the `HEAD` commit. The ancestry graph looks like this:
+
+ .----W
+ / /
+ ...--H----I
+
+where `H` is the `HEAD` commit, `I` is a commit that records the state
+of the index, and `W` is a commit that records the state of the working
+tree.
+
+
+EXAMPLES
+--------
+
+Pulling into a dirty tree::
+
+When you are in the middle of something, you learn that there are
+upstream changes that are possibly relevant to what you are
+doing. When your local changes do not conflict with the changes in
+the upstream, a simple `git pull` will let you move forward.
++
+However, there are cases in which your local changes do conflict with
+the upstream changes, and `git pull` refuses to overwrite your
+changes. In such a case, you can stash your changes away,
+perform a pull, and then unstash, like this:
++
+----------------------------------------------------------------
+$ git pull
+...
+file foobar not up to date, cannot merge.
+$ git stash
+$ git pull
+$ git stash apply
+----------------------------------------------------------------
+
+Interrupted workflow::
+
+When you are in the middle of something, your boss comes in and
+demands that you fix something immediately. Traditionally, you would
+make a commit to a temporary branch to store your changes away, and
+return to your original branch to make the emergency fix, like this:
++
+----------------------------------------------------------------
+... hack hack hack ...
+$ git checkout -b my_wip
+$ git commit -a -m "WIP"
+$ git checkout master
+$ edit emergency fix
+$ git commit -a -m "Fix in a hurry"
+$ git checkout my_wip
+$ git reset --soft HEAD^
+... continue hacking ...
+----------------------------------------------------------------
++
+You can use `git-stash` to simplify the above, like this:
++
+----------------------------------------------------------------
+... hack hack hack ...
+$ git stash
+$ edit emergency fix
+$ git commit -a -m "Fix in a hurry"
+$ git stash apply
+... continue hacking ...
+----------------------------------------------------------------
+
+SEE ALSO
+--------
+gitlink:git-checkout[1],
+gitlink:git-commit[1],
+gitlink:git-reflog[1],
+gitlink:git-reset[1]
+
+AUTHOR
+------
+Written by Nanako Shiraishi <nanako3@bluebottle.com>
+
+GIT
+---
+Part of the gitlink:git[7] suite
</div>\r
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
-<p><em>git-submodule</em> [--quiet] [--cached] [status|init|update] [--] [<path>…]</p>\r
+<p><em>git-submodule</em> [--quiet] [-b branch] add <repository> [<path>]\r
+<em>git-submodule</em> [--quiet] [--cached] [status|init|update] [--] [<path>…]</p>\r
</div>\r
<h2>COMMANDS</h2>\r
<div class="sectionbody">\r
<dl>\r
<dt>\r
+add\r
+</dt>\r
+<dd>\r
+<p>\r
+ Add the given repository as a submodule at the given path\r
+ to the changeset to be committed next. In particular, the\r
+ repository is cloned at the specified path, added to the\r
+ changeset and registered in .gitmodules. If no path is\r
+ specified, the path is deduced from the repository specification.\r
+</p>\r
+</dd>\r
+<dt>\r
status\r
</dt>\r
<dd>\r
</p>\r
</dd>\r
<dt>\r
+-b, --branch\r
+</dt>\r
+<dd>\r
+<p>\r
+ Branch of repository to add as submodule.\r
+</p>\r
+</dd>\r
+<dt>\r
--cached\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 16-Jun-2007 09:49:24 UTC\r
+Last updated 03-Jul-2007 07:03:46 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
+'git-submodule' [--quiet] [-b branch] add <repository> [<path>]
'git-submodule' [--quiet] [--cached] [status|init|update] [--] [<path>...]
COMMANDS
--------
+add::
+ Add the given repository as a submodule at the given path
+ to the changeset to be committed next. In particular, the
+ repository is cloned at the specified path, added to the
+ changeset and registered in .gitmodules. If no path is
+ specified, the path is deduced from the repository specification.
+
status::
Show the status of the submodules. This will print the SHA-1 of the
currently checked out commit for each submodule, along with the
-q, --quiet::
Only print error messages.
+-b, --branch::
+ Branch of repository to add as submodule.
+
--cached::
Display the SHA-1 stored in the index, not the SHA-1 of the currently
checked out submodule commit. This option is only valid for the
</p>\r
</dd>\r
<dt>\r
+<a href="git-stash.html">git-stash(1)</a>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Stash the changes in a dirty working directory away.\r
+</p>\r
+</dd>\r
+<dt>\r
<a href="git-status.html">git-status(1)</a>\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 02-Jul-2007 00:17:00 UTC\r
+Last updated 03-Jul-2007 07:03:47 UTC\r
</div>\r
</div>\r
</body>\r
branch of the `git.git` repository.
Documentation for older releases are available here:
-* link:v1.5.2.2/git.html[documentation for release 1.5.2.2]
+* link:v1.5.2.3/git.html[documentation for release 1.5.2.3]
* release notes for
+ link:RelNotes-1.5.2.3.txt[1.5.2.3],
link:RelNotes-1.5.2.2.txt[1.5.2.2],
link:RelNotes-1.5.2.1.txt[1.5.2.1],
link:RelNotes-1.5.2.txt[1.5.2].
projects / git.git / commitdiff