--- /dev/null
+GIT v1.5.0.2 Release Notes
+==========================
+
+Fixes since v1.5.0.2
+--------------------
+
+* Bugfixes
+
+ - 'git.el' honors the commit coding system from the configuration.
+
+ - 'blameview' in contrib/ correctly digs deeper when a line is
+ clicked.
+
+ - 'http-push' correctly makes sure the remote side has leading
+ path. Earlier it started in the middle of the path, and
+ incorrectly.
+
+ - 'cvsexportcommit' does not lose yet-to-be-used message file.
+
+ - int-vs-size_t typefix when running combined diff on files
+ over 2GB long.
+
+ - 'git apply --whitespace=strip' should not touch unmodified
+ lines.
+
+ - 'git-mailinfo' choke when a logical header line was too long.
+
+ - 'git show A..B' did not error out. Negative ref ("not A" in
+ this example) does not make sense for the purpose of the
+ command, so now it errors out.
+
+ - 'git fmt-merge-msg --file' without file parameter did not
+ correctly error out.
+
+ - 'git archimport' barfed upon encountering a commit without
+ summary.
+
+ - 'git index-pack' did not protect itself from getting a short
+ read out of pread(2).
+
+* Documentation updates
+
+ - options to 'git remote add' were described insufficiently.
+
+
+---
+exec >/var/tmp/1
+O=v1.5.0.2
+O=v1.5.0.2-16-gdb554bf
+echo O=`git describe maint`
+git shortlog --no-merges $O..maint
+
+# Local Variables:
+# mode: text
+# End:
- "git diff" learned --ignore-space-at-eol. This is a weaker
form of --ignore-space-change.
+ - "git diff --no-index pathA pathB" can be used as diff
+ replacement with git specific enhancements.
+
- "git name-rev" learned --refs=<pattern>, to limit the tags
used for naming the given revisions only to the ones
matching the given pattern.
+ - "git remote update" is to run "git fetch" for defined remotes
+ to update tracking branches.
+
+ - "git cvsimport" can now take '-d' to talk with a CVS
+ repository different from what are recorded in CVS/Root
+ (overriding it with environment CVSROOT does not work).
+
+ - "git bundle" can help sneaker-netting your changes between
+ repositories.
+
+
* Updated behaviour of existing commands.
+ - git-svn got almost a rewrite.
+
+ - core.autocrlf configuration, when set to 'true', makes git
+ to convert CRLF at the end of lines in text files to LF when
+ reading from the filesystem, and convert in reverse when
+ writing to the filesystem. The variable can be set to
+ 'input', in which case the conversion happens only while
+ reading from the filesystem but files are written out with
+ LF at the end of lines. Currently, which paths to consider
+ 'text' (i.e. be subjected to the autocrlf mechanism) is
+ decided purely based on the contents, but the plan is to
+ allow users to explicitly override this heuristics based on
+ paths.
+
+ - The behaviour of 'git-apply', when run in a subdirectory,
+ without --index nor --cached were inconsistent with that of
+ the command with these options. This was fixed to match the
+ behaviour with --index. A patch that is meant to be applied
+ with -p1 from the toplevel of the project tree can be
+ applied with any custom -p<n> option. A patch that is not
+ relative to the toplevel needs to be applied with -p<n>
+ option with or without --index (or --cached).
+
- "git diff" outputs a trailing HT when pathnames have embedded
SP on +++/--- header lines, in order to help "GNU patch" to
parse its output. "git apply" was already updated to accept
this modified output format since ce74618d (Sep 22, 2006).
+ - "git cvsserver" runs hooks/update and honors its exit status.
+
+ - "git cvsserver" can be told to send everything with -kb.
+
+ - "git diff --check" also honors the --color output option.
+
+ - "git name-rev" used to stress the fact that a ref is a tag too
+ much, by saying something like "v1.2.3^0~22". It now says
+ "v1.2.3~22" in such a case (it still says "v1.2.3^0" if it does
+ not talk about an ancestor of the commit that is tagged, which
+ makes sense).
+
+ - "git rev-list --boundary" now shows boundary markers for the
+ commits omitted by --max-age and --max-count condition.
+
+ - The configuration mechanism now reads $(prefix)/etc/gitconfig.
+
+ - "git apply --verbose" shows what preimage lines were wanted
+ when it couldn't find them.
+
+ - "git status" in a read-only repository got a bit saner.
+
* Hooks
- The sample update hook to show how to send out notification
--
exec >/var/tmp/1
-O=v1.5.0-49-g69bc0e2
+O=v1.5.0.2-259-g16d5315
echo O=`git describe master`
git shortlog --no-merges $O..master ^maint
+
+# Local Variables:
+# mode: text
+# End:
gitlink:git-branch[1]::
List, create, or delete branches.
+gitlink:git-bundle[1]::
+ Move objects and refs by archive.
+
gitlink:git-checkout[1]::
Checkout and switch to a branch.
--- /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-bundle(1)</title>\r
+</head>\r
+<body>\r
+<div id="header">\r
+<h1>\r
+git-bundle(1) Manual Page\r
+</h1>\r
+<h2>NAME</h2>\r
+<div class="sectionbody">\r
+<p>git-bundle -\r
+ Move objects and refs by archive\r
+</p>\r
+</div>\r
+</div>\r
+<h2>SYNOPSIS</h2>\r
+<div class="sectionbody">\r
+<p><em>git-bundle</em> create <file> [git-rev-list args]\r
+<em>git-bundle</em> verify <file>\r
+<em>git-bundle</em> list-heads <file> [refname…]\r
+<em>git-bundle</em> unbundle <file> [refname…]</p>\r
+</div>\r
+<h2>DESCRIPTION</h2>\r
+<div class="sectionbody">\r
+<p>Some workflows require that one or more branches of development on one\r
+machine be replicated on another machine, but the two machines cannot\r
+be directly connected so the interactive git protocols (git, ssh,\r
+rsync, http) cannot be used. This command provides suport for\r
+git-fetch and git-pull to operate by packaging objects and references\r
+in an archive at the originating machine, then importing those into\r
+another repository using <a href="git-fetch.html">git-fetch(1)</a> and <a href="git-pull.html">git-pull(1)</a>\r
+after moving the archive by some means (i.e., by sneakernet). As no\r
+direct connection between repositories exists, the user must specify a\r
+basis for the bundle that is held by the destination repository: the\r
+bundle assumes that all objects in the basis are already in the\r
+destination repository.</p>\r
+</div>\r
+<h2>OPTIONS</h2>\r
+<div class="sectionbody">\r
+<dl>\r
+<dt>\r
+create <file>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Used to create a bundle named <em>file</em>. This requires the\r
+ git-rev-list arguments to define the bundle contents.\r
+</p>\r
+</dd>\r
+<dt>\r
+verify <file>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Used to check that a bundle file is valid and will apply\r
+ cleanly to the current repository. This includes checks on the\r
+ bundle format itself as well as checking that the prerequisite\r
+ commits exist and are fully linked in the current repository.\r
+ git-bundle prints a list of missing commits, if any, and exits\r
+ with non-zero status.\r
+</p>\r
+</dd>\r
+<dt>\r
+list-heads <file>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Lists the references defined in the bundle. If followed by a\r
+ list of references, only references matching those given are\r
+ printed out.\r
+</p>\r
+</dd>\r
+<dt>\r
+unbundle <file>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Passes the objects in the bundle to <a href="git-index-pack.html">git-index-pack(1)</a>\r
+ for storage in the repository, then prints the names of all\r
+ defined references. If a reflist is given, only references\r
+ matching those in the given list are printed. This command is\r
+ really plumbing, intended to be called only by\r
+ <a href="git-fetch.html">git-fetch(1)</a>.\r
+</p>\r
+</dd>\r
+<dt>\r
+[git-rev-list-args…]\r
+</dt>\r
+<dd>\r
+<p>\r
+ A list of arguments, accepatble to git-rev-parse and\r
+ git-rev-list, that specify the specific objects and references\r
+ to transport. For example, "master~10..master" causes the\r
+ current master reference to be packaged along with all objects\r
+ added since its 10th ancestor commit. There is no explicit\r
+ limit to the number of references and objects that may be\r
+ packaged.\r
+</p>\r
+</dd>\r
+<dt>\r
+[refname…]\r
+</dt>\r
+<dd>\r
+<p>\r
+ A list of references used to limit the references reported as\r
+ available. This is principally of use to git-fetch, which\r
+ expects to recieve only those references asked for and not\r
+ necessarily everything in the pack (in this case, git-bundle is\r
+ acting like <a href="git-fetch-pack.html">git-fetch-pack(1)</a>).\r
+</p>\r
+</dd>\r
+</dl>\r
+</div>\r
+<h2>SPECIFYING REFERENCES</h2>\r
+<div class="sectionbody">\r
+<p>git-bundle will only package references that are shown by\r
+git-show-ref: this includes heads, tags, and remote heads. References\r
+such as master~1 cannot be packaged, but are perfectly suitable for\r
+defining the basis. More than one reference may be packaged, and more\r
+than one basis can be specified. The objects packaged are those not\r
+contained in the union of the given bases. Each basis can be\r
+specified explicitly (e.g., ^master~10), or implicitly (e.g.,\r
+master~10..master, master --since=10.days.ago).</p>\r
+<p>It is very important that the basis used be held by the destination.\r
+It is ok to err on the side of conservatism, causing the bundle file\r
+to contain objects already in the destination as these are ignored\r
+when unpacking at the destination.</p>\r
+</div>\r
+<h2>EXAMPLE</h2>\r
+<div class="sectionbody">\r
+<p>Assume two repositories exist as R1 on machine A, and R2 on machine B.\r
+For whatever reason, direct connection between A and B is not allowed,\r
+but we can move data from A to B via some mechanism (CD, email, etc).\r
+We want to update R2 with developments made on branch master in R1.\r
+We set a tag in R1 (lastR2bundle) after the previous such transport,\r
+and move it afterwards to help build the bundle.</p>\r
+<p>in R1 on A:\r
+$ git-bundle create mybundle master ^lastR2bundle\r
+$ git tag -f lastR2bundle master</p>\r
+<p>(move mybundle from A to B by some mechanism)</p>\r
+<p>in R2 on B:\r
+$ git-bundle verify mybundle\r
+$ git-fetch mybundle refspec</p>\r
+<p>where refspec is refInBundle:localRef</p>\r
+<p>Also, with something like this in your config:</p>\r
+<div class="literalblock">\r
+<div class="content">\r
+<pre><tt>url = /home/me/tmp/file.bdl\r
+fetch = refs/heads/*:refs/remotes/origin/*</tt></pre>\r
+</div></div>\r
+<p>You can first sneakernet the bundle file to ~/tmp/file.bdl and\r
+then these commands:</p>\r
+<p>$ git ls-remote bundle\r
+$ git fetch bundle\r
+$ git pull bundle</p>\r
+<p>would treat it as if it is talking with a remote side over the\r
+network.</p>\r
+</div>\r
+<h2>Author</h2>\r
+<div class="sectionbody">\r
+<p>Written by Mark Levedahl <mdl123@verizon.net></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 01-Mar-2007 01:24:42 UTC\r
+</div>\r
+</div>\r
+</body>\r
+</html>\r
--- /dev/null
+git-bundle(1)
+=============
+
+NAME
+----
+git-bundle - Move objects and refs by archive
+
+
+SYNOPSIS
+--------
+'git-bundle' create <file> [git-rev-list args]
+'git-bundle' verify <file>
+'git-bundle' list-heads <file> [refname...]
+'git-bundle' unbundle <file> [refname...]
+
+DESCRIPTION
+-----------
+
+Some workflows require that one or more branches of development on one
+machine be replicated on another machine, but the two machines cannot
+be directly connected so the interactive git protocols (git, ssh,
+rsync, http) cannot be used. This command provides suport for
+git-fetch and git-pull to operate by packaging objects and references
+in an archive at the originating machine, then importing those into
+another repository using gitlink:git-fetch[1] and gitlink:git-pull[1]
+after moving the archive by some means (i.e., by sneakernet). As no
+direct connection between repositories exists, the user must specify a
+basis for the bundle that is held by the destination repository: the
+bundle assumes that all objects in the basis are already in the
+destination repository.
+
+OPTIONS
+-------
+
+create <file>::
+ Used to create a bundle named 'file'. This requires the
+ git-rev-list arguments to define the bundle contents.
+
+verify <file>::
+ Used to check that a bundle file is valid and will apply
+ cleanly to the current repository. This includes checks on the
+ bundle format itself as well as checking that the prerequisite
+ commits exist and are fully linked in the current repository.
+ git-bundle prints a list of missing commits, if any, and exits
+ with non-zero status.
+
+list-heads <file>::
+ Lists the references defined in the bundle. If followed by a
+ list of references, only references matching those given are
+ printed out.
+
+unbundle <file>::
+ Passes the objects in the bundle to gitlink:git-index-pack[1]
+ for storage in the repository, then prints the names of all
+ defined references. If a reflist is given, only references
+ matching those in the given list are printed. This command is
+ really plumbing, intended to be called only by
+ gitlink:git-fetch[1].
+
+[git-rev-list-args...]::
+ A list of arguments, accepatble to git-rev-parse and
+ git-rev-list, that specify the specific objects and references
+ to transport. For example, "master~10..master" causes the
+ current master reference to be packaged along with all objects
+ added since its 10th ancestor commit. There is no explicit
+ limit to the number of references and objects that may be
+ packaged.
+
+
+[refname...]::
+ A list of references used to limit the references reported as
+ available. This is principally of use to git-fetch, which
+ expects to recieve only those references asked for and not
+ necessarily everything in the pack (in this case, git-bundle is
+ acting like gitlink:git-fetch-pack[1]).
+
+SPECIFYING REFERENCES
+---------------------
+
+git-bundle will only package references that are shown by
+git-show-ref: this includes heads, tags, and remote heads. References
+such as master~1 cannot be packaged, but are perfectly suitable for
+defining the basis. More than one reference may be packaged, and more
+than one basis can be specified. The objects packaged are those not
+contained in the union of the given bases. Each basis can be
+specified explicitly (e.g., ^master~10), or implicitly (e.g.,
+master~10..master, master --since=10.days.ago).
+
+It is very important that the basis used be held by the destination.
+It is ok to err on the side of conservatism, causing the bundle file
+to contain objects already in the destination as these are ignored
+when unpacking at the destination.
+
+EXAMPLE
+-------
+
+Assume two repositories exist as R1 on machine A, and R2 on machine B.
+For whatever reason, direct connection between A and B is not allowed,
+but we can move data from A to B via some mechanism (CD, email, etc).
+We want to update R2 with developments made on branch master in R1.
+We set a tag in R1 (lastR2bundle) after the previous such transport,
+and move it afterwards to help build the bundle.
+
+in R1 on A:
+$ git-bundle create mybundle master ^lastR2bundle
+$ git tag -f lastR2bundle master
+
+(move mybundle from A to B by some mechanism)
+
+in R2 on B:
+$ git-bundle verify mybundle
+$ git-fetch mybundle refspec
+
+where refspec is refInBundle:localRef
+
+
+Also, with something like this in your config:
+
+[remote "bundle"]
+ url = /home/me/tmp/file.bdl
+ fetch = refs/heads/*:refs/remotes/origin/*
+
+You can first sneakernet the bundle file to ~/tmp/file.bdl and
+then these commands:
+
+$ git ls-remote bundle
+$ git fetch bundle
+$ git pull bundle
+
+would treat it as if it is talking with a remote side over the
+network.
+
+Author
+------
+Written by Mark Levedahl <mdl123@verizon.net>
+
+GIT
+---
+Part of the gitlink:git[7] suite
<div class="sectionbody">\r
<div class="verseblock">\r
<div class="content"><em>git-remote</em>\r
-<em>git-remote</em> add <name> <url>\r
+<em>git-remote</em> add [-t <branch>] [-m <branch>] [-f] <name> <url>\r
<em>git-remote</em> show <name>\r
<em>git-remote</em> prune <name>\r
<em>git-remote</em> update [group]</div></div>\r
</div>\r
<h2>Examples</h2>\r
<div class="sectionbody">\r
-<p>Add a new remote, fetch, and check out a branch from it:</p>\r
+<ul>\r
+<li>\r
+<p>\r
+Add a new remote, fetch, and check out a branch from it\r
+</p>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>$ git remote\r
$ git checkout -b nfs linux-nfs/master\r
...</tt></pre>\r
</div></div>\r
+</li>\r
+<li>\r
+<p>\r
+Imitate <em>git clone</em> but track only selected branches\r
+</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ mkdir project.git\r
+$ cd project.git\r
+$ git init\r
+$ git remote add -f -t master -m master origin git://example.com/git.git/\r
+$ git merge origin</tt></pre>\r
+</div></div>\r
+</li>\r
+</ul>\r
</div>\r
<h2>See Also</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 26-Feb-2007 09:50:09 UTC\r
+Last updated 01-Mar-2007 01:24:43 UTC\r
</div>\r
</div>\r
</body>\r
--------
[verse]
'git-remote'
-'git-remote' add <name> <url>
+'git-remote' add [-t <branch>] [-m <branch>] [-f] <name> <url>
'git-remote' show <name>
'git-remote' prune <name>
'git-remote' update [group]
Examples
--------
-Add a new remote, fetch, and check out a branch from it:
-
+* Add a new remote, fetch, and check out a branch from it
++
------------
$ git remote
origin
...
------------
+* Imitate 'git clone' but track only selected branches
++
+------------
+$ mkdir project.git
+$ cd project.git
+$ git init
+$ git remote add -f -t master -m master origin git://example.com/git.git/
+$ git merge origin
+------------
+
+
See Also
--------
gitlink:git-fetch[1]
</li>\r
<li>\r
<p>\r
+A colon, followed by a slash, followed by a text: this names\r
+ a commit whose commit message starts with the specified text.\r
+ This name returns the youngest matching commit which is\r
+ reachable from any ref. If the commit message starts with a\r
+ <em>!</em>, you have to repeat that; the special sequence <em>:/!</em>,\r
+ followed by something else than <em>!</em> is reserved for now.\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
A suffix <em>:</em> followed by a path; this names the blob or tree\r
at the given path in the tree-ish object named by the part\r
before the colon.\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 02-Feb-2007 07:34:53 UTC\r
+Last updated 01-Mar-2007 01:24:43 UTC\r
</div>\r
</div>\r
</body>\r
and dereference the tag recursively until a non-tag object is
found.
+* A colon, followed by a slash, followed by a text: this names
+ a commit whose commit message starts with the specified text.
+ This name returns the youngest matching commit which is
+ reachable from any ref. If the commit message starts with a
+ '!', you have to repeat that; the special sequence ':/!',
+ followed by something else than '!' is reserved for now.
+
* A suffix ':' followed by a path; this names the blob or tree
at the given path in the tree-ish object named by the part
before the colon.
</p>\r
</dd>\r
<dt>\r
+<a href="git-bundle.html">git-bundle(1)</a>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Move objects and refs by archive.\r
+</p>\r
+</dd>\r
+<dt>\r
<a href="git-checkout.html">git-checkout(1)</a>\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 28-Feb-2007 08:13:34 UTC\r
+Last updated 01-Mar-2007 01:24:44 UTC\r
</div>\r
</div>\r
</body>\r