Permalink
Browse files

Autogenerated HTML docs for v1.8.5.1-163-gd7ace

  • Loading branch information...
gitster committed Dec 13, 2013
1 parent f079f70 commit 4c8f2d99229331de853716af53a6a0901b4b0d68
View
@@ -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.
@@ -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.
@@ -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.
-
@@ -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.
View
@@ -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.
View
@@ -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>::
View
@@ -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
View
@@ -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>
Oops, something went wrong.

0 comments on commit 4c8f2d9

Please sign in to comment.