Autogenerated HTML docs for v1.8.5.1-163-gd7ace

RelNotes/1.9.txt

@@ -15,6 +15,13 @@ Read-only support for experimental loose-object format, in which users
 could optionally choose to write in their loose objects for a short
 while between v1.4.3 to v1.5.3 era, has been dropped.
 
+The meanings of "--tags" option to "git fetch" has changed; the
+command fetches tags _in addition to_ what are fetched by the same
+command line without the option.
+
+A handful of ancient commands that have long been deprecated are
+finally gone (repo-config, tar-tree, lost-found, and peek-remote).
+
 
 Backward compatibility notes (for Git 2.0)
 ------------------------------------------
@@ -68,7 +75,7 @@ Updates since v1.8.5
 
 Foreign interfaces, subsystems and ports.
 
- * The HTTP transport, when talking GSS-Negotinate, uses "100
+ * The HTTP transport, when talking GSS-Negotiate, uses "100
    Continue" response to avoid having to rewind and resend a large
    payload, which may not be always doable.
 
@@ -91,6 +98,10 @@ UI, Workflows & Features
  * "git rev-parse --parseopt" learned a new "--stuck-long" option to
    help scripts parse options with an optional parameter.
 
+ * The "--tags" option to "git fetch" no longer tells the command to
+   fetch _only_ the tags. It instead fetches tags _in addition to_
+   what are fetched by the same command line without the option.
+
 
 Performance, Internal Implementation, etc.
 
@@ -103,6 +114,11 @@ Performance, Internal Implementation, etc.
    point out of the reflog entries for the remote-tracking branch the
    work has been based on.
 
+ * A third-party "receive-pack" (the responder to "git push") can
+   advertise the "no-thin" capability to tell "git push" not to use
+   the thin-pack optimization. Our receive-pack has always been
+   capable of accepting and fattening a thin-pack, and will continue
+   not to ask "git push" to use a non-thin pack.
 
 
 Also contains various documentation updates and code clean-ups.

cmds-ancillaryinterrogators.txt

@@ -5,7 +5,7 @@ linkgit:git-blame[1]::
 	Show what revision and author last modified each line of a file.
 
 linkgit:git-cherry[1]::
-	Find commits not merged upstream.
+	Find commits yet to be applied to upstream.
 
 linkgit:git-count-objects[1]::
 	Count unpacked number of objects and their disk consumption.

cmds-ancillarymanipulators.txt

@@ -10,9 +10,6 @@ linkgit:git-fast-import[1]::
 linkgit:git-filter-branch[1]::
 	Rewrite branches.
 
-linkgit:git-lost-found[1]::
-	(deprecated) Recover lost refs that luckily have not yet been pruned.
-
 linkgit:git-mergetool[1]::
 	Run merge conflict resolution tools to resolve merge conflicts.
 
@@ -37,6 +34,3 @@ linkgit:git-repack[1]::
 linkgit:git-replace[1]::
 	Create, list, delete refs to replace objects.
 
-linkgit:git-repo-config[1]::
-	(deprecated) Get and set repository or global options.
-

cmds-plumbinginterrogators.txt

@@ -40,9 +40,6 @@ linkgit:git-show-index[1]::
 linkgit:git-show-ref[1]::
 	List references in a local repository.
 
-linkgit:git-tar-tree[1]::
-	(deprecated) Create a tar archive of the files in the named tree object.
-
 linkgit:git-unpack-file[1]::
 	Creates a temporary file with a blob's contents.
 

cmds-purehelpers.txt

@@ -37,9 +37,6 @@ linkgit:git-merge-one-file[1]::
 linkgit:git-patch-id[1]::
 	Compute unique ID for a patch.
 
-linkgit:git-peek-remote[1]::
-	(deprecated) List the references in a remote repository.
-
 linkgit:git-sh-i18n[1]::
 	Git's i18n setup code for shell scripts.
 

config.txt

@@ -2087,8 +2087,8 @@ remote.<name>.vcs::
 
 remote.<name>.prune::
 	When set to true, fetching from this remote by default will also
-	remove any remote-tracking branches which no longer exist on the
-	remote (as if the `--prune` option was give on the command line).
+	remove any remote-tracking references that no longer exist on the
+	remote (as if the `--prune` option was given on the command line).
 	Overrides `fetch.prune` settings, if any.
 
 remotes.<group>::

fetch-options.txt

@@ -41,17 +41,20 @@ ifndef::git-pull[]
 
 -p::
 --prune::
-	After fetching, remove any remote-tracking branches which
-	no longer exist	on the remote.
+	After fetching, remove any remote-tracking references that no
+	longer exist on the remote.  Tags are not subject to pruning
+	if they are fetched only because of the default tag
+	auto-following or due to a --tags option.  However, if tags
+	are fetched due to an explicit refspec (either on the command
+	line or in the remote configuration, for example if the remote
+	was cloned with the --mirror option), then they are also
+	subject to pruning.
 endif::git-pull[]
 
-ifdef::git-pull[]
---no-tags::
-endif::git-pull[]
 ifndef::git-pull[]
 -n::
---no-tags::
 endif::git-pull[]
+--no-tags::
 	By default, tags that point at objects that are downloaded
 	from the remote repository are fetched and stored locally.
 	This option disables this automatic tag following. The default
@@ -61,11 +64,12 @@ endif::git-pull[]
 ifndef::git-pull[]
 -t::
 --tags::
-	This is a short-hand for giving `refs/tags/*:refs/tags/*`
-	refspec from the command line, to ask all tags to be fetched
-	and stored locally.  Because this acts as an explicit
-	refspec, the default refspecs (configured with the
-	remote.$name.fetch variable) are overridden and not used.
+	Fetch all tags from the remote (i.e., fetch remote tags
+	`refs/tags/*` into local tags with the same name), in addition
+	to whatever else would otherwise be fetched.  Using this
+	option alone does not subject tags to pruning, even if --prune
+	is used (though tags may be pruned anyway if they are also the
+	destination of an explicit refspec; see '--prune').
 
 --recurse-submodules[=yes|on-demand|no]::
 	This option controls if and under what conditions new commits of

git-cherry.html

@@ -737,7 +737,7 @@ <h1>
 <h2>NAME</h2>
 <div class="sectionbody">
 <p>git-cherry -
-   Find commits not merged upstream
+   Find commits yet to be applied to upstream
 </p>
 </div>
 </div>
@@ -754,35 +754,15 @@ <h2 id="_synopsis">SYNOPSIS</h2>
 <div class="sect1">
 <h2 id="_description">DESCRIPTION</h2>
 <div class="sectionbody">
-<div class="paragraph"><p>The changeset (or "diff") of each commit between the fork-point and &lt;head&gt;
-is compared against each commit between the fork-point and &lt;upstream&gt;.
-The diffs are compared after removing any whitespace and line numbers.</p></div>
-<div class="paragraph"><p>Every commit that doesn&#8217;t exist in the &lt;upstream&gt; branch
-has its id (sha1) reported, prefixed by a symbol.  The ones that have
-equivalent change already
-in the &lt;upstream&gt; branch are prefixed with a minus (-) sign, and those
-that only exist in the &lt;head&gt; branch are prefixed with a plus (+) symbol:</p></div>
-<div class="literalblock">
-<div class="content">
-<pre><code>           __*__*__*__*__&gt; &lt;upstream&gt;
-          /
-fork-point
-          \__+__+__-__+__+__-__+__&gt; &lt;head&gt;</code></pre>
-</div></div>
-<div class="paragraph"><p>If a &lt;limit&gt; has been given then the commits along the &lt;head&gt; branch up
-to and including &lt;limit&gt; are not reported:</p></div>
-<div class="literalblock">
-<div class="content">
-<pre><code>           __*__*__*__*__&gt; &lt;upstream&gt;
-          /
-fork-point
-          \__*__*__&lt;limit&gt;__-__+__&gt; &lt;head&gt;</code></pre>
-</div></div>
-<div class="paragraph"><p>Because <em>git cherry</em> compares the changeset rather than the commit id
-(sha1), you can use <em>git cherry</em> to find out if a commit you made locally
-has been applied &lt;upstream&gt; under a different commit id.  For example,
-this will happen if you&#8217;re feeding patches &lt;upstream&gt; via email rather
-than pushing or pulling commits directly.</p></div>
+<div class="paragraph"><p>Determine whether there are commits in <code>&lt;head&gt;..&lt;upstream&gt;</code> that are
+equivalent to those in the range <code>&lt;limit&gt;..&lt;head&gt;</code>.</p></div>
+<div class="paragraph"><p>The equivalence test is based on the diff, after removing whitespace
+and line numbers.  git-cherry therefore detects when commits have been
+"copied" by means of <a href="git-cherry-pick.html">git-cherry-pick(1)</a>, <a href="git-am.html">git-am(1)</a> or
+<a href="git-rebase.html">git-rebase(1)</a>.</p></div>
+<div class="paragraph"><p>Outputs the SHA1 of every commit in <code>&lt;limit&gt;..&lt;head&gt;</code>, prefixed with
+<code>-</code> for commits that have an equivalent in &lt;upstream&gt;, and <code>+</code> for
+commits that do not.</p></div>
 </div>
 </div>
 <div class="sect1">
@@ -794,16 +774,16 @@ <h2 id="_options">OPTIONS</h2>
 </dt>
 <dd>
 <p>
-        Verbose.
+        Show the commit subjects next to the SHA1s.
 </p>
 </dd>
 <dt class="hdlist1">
 &lt;upstream&gt;
 </dt>
 <dd>
 <p>
-        Upstream branch to compare against.
-        Defaults to the first tracked remote branch, if available.
+        Upstream branch to search for equivalent commits.
+        Defaults to the upstream branch of HEAD.
 </p>
 </dd>
 <dt class="hdlist1">
@@ -826,6 +806,96 @@ <h2 id="_options">OPTIONS</h2>
 </div>
 </div>
 <div class="sect1">
+<h2 id="_examples">EXAMPLES</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_patch_workflows">Patch workflows</h3>
+<div class="paragraph"><p>git-cherry is frequently used in patch-based workflows (see
+<a href="gitworkflows.html">gitworkflows(7)</a>) to determine if a series of patches has been
+applied by the upstream maintainer.  In such a workflow you might
+create and send a topic branch like this:</p></div>
+<div class="listingblock">
+<div class="content">
+<pre><code>$ git checkout -b topic origin/master
+# work and create some commits
+$ git format-patch origin/master
+$ git send-email ... 00*</code></pre>
+</div></div>
+<div class="paragraph"><p>Later, you can see whether your changes have been applied by saying
+(still on <code>topic</code>):</p></div>
+<div class="listingblock">
+<div class="content">
+<pre><code>$ git fetch  # update your notion of origin/master
+$ git cherry -v</code></pre>
+</div></div>
+</div>
+<div class="sect2">
+<h3 id="_concrete_example">Concrete example</h3>
+<div class="paragraph"><p>In a situation where topic consisted of three commits, and the
+maintainer applied two of them, the situation might look like:</p></div>
+<div class="listingblock">
+<div class="content">
+<pre><code>$ git log --graph --oneline --decorate --boundary origin/master...topic
+* 7654321 (origin/master) upstream tip commit
+[... snip some other commits ...]
+* cccc111 cherry-pick of C
+* aaaa111 cherry-pick of A
+[... snip a lot more that has happened ...]
+| * cccc000 (topic) commit C
+| * bbbb000 commit B
+| * aaaa000 commit A
+|/
+o 1234567 branch point</code></pre>
+</div></div>
+<div class="paragraph"><p>In such cases, git-cherry shows a concise summary of what has yet to
+be applied:</p></div>
+<div class="listingblock">
+<div class="content">
+<pre><code>$ git cherry origin/master topic
+- cccc000... commit C
++ bbbb000... commit B
+- aaaa000... commit A</code></pre>
+</div></div>
+<div class="paragraph"><p>Here, we see that the commits A and C (marked with <code>-</code>) can be
+dropped from your <code>topic</code> branch when you rebase it on top of
+<code>origin/master</code>, while the commit B (marked with <code>+</code>) still needs to
+be kept so that it will be sent to be applied to <code>origin/master</code>.</p></div>
+</div>
+<div class="sect2">
+<h3 id="_using_a_limit">Using a limit</h3>
+<div class="paragraph"><p>The optional &lt;limit&gt; is useful in cases where your topic is based on
+other work that is not in upstream.  Expanding on the previous
+example, this might look like:</p></div>
+<div class="listingblock">
+<div class="content">
+<pre><code>$ git log --graph --oneline --decorate --boundary origin/master...topic
+* 7654321 (origin/master) upstream tip commit
+[... snip some other commits ...]
+* cccc111 cherry-pick of C
+* aaaa111 cherry-pick of A
+[... snip a lot more that has happened ...]
+| * cccc000 (topic) commit C
+| * bbbb000 commit B
+| * aaaa000 commit A
+| * 0000fff (base) unpublished stuff F
+[... snip ...]
+| * 0000aaa unpublished stuff A
+|/
+o 1234567 merge-base between upstream and topic</code></pre>
+</div></div>
+<div class="paragraph"><p>By specifying <code>base</code> as the limit, you can avoid listing commits
+between <code>base</code> and <code>topic</code>:</p></div>
+<div class="listingblock">
+<div class="content">
+<pre><code>$ git cherry origin/master topic base
+- cccc000... commit C
++ bbbb000... commit B
+- aaaa000... commit A</code></pre>
+</div></div>
+</div>
+</div>
+</div>
+<div class="sect1">
 <h2 id="_see_also">SEE ALSO</h2>
 <div class="sectionbody">
 <div class="paragraph"><p><a href="git-patch-id.html">git-patch-id(1)</a></p></div>
@@ -841,7 +911,7 @@ <h2 id="_git">GIT</h2>
 <div id="footnotes"><hr /></div>
 <div id="footer">
 <div id="footer-text">
-Last updated 2013-10-15 11:39:58 PDT
+Last updated 2013-12-12 16:55:14 PST
 </div>
 </div>
 </body>