StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Note: starting with <a href="https://github.com/git/git/blob/d7aced95cd681b761468635f8d2a8b82d7ed26fd/Documentation/RelNotes/1.9.txt#L18-L20">git 1.9/2.0 (Q1 2014)</a>, <code>git fetch --tags</code> fetches tags <em>in addition to</em> what are fetched by the same command line without the option.</p> <p>See <a href="https://github.com/git/git/commit/c5a84e92a2fe9e8748e32341c344d7a6c0f52a50">commit c5a84e9</a> by <a href="https://github.com/mhagger">Michael Haggerty (mhagger)</a>:</p> <blockquote> <p>Previously, fetch's "<code>--tags</code>" option was considered equivalent to specifying the refspec </p> <pre><code>refs/tags/*:refs/tags/* </code></pre> <p>on the command line; in particular, it caused the <code>remote.<name>.refspec</code> configuration to be ignored.</p> <p>But it is not very useful to fetch tags without also fetching other references, whereas it <em>is</em> quite useful to be able to fetch tags <em>in addition to</em> other references.<br> So change the semantics of this option to do the latter.</p> <p>If a user wants to fetch <em>only</em> tags, then it is still possible to specifying an explicit refspec:</p> <pre><code>git fetch <remote> 'refs/tags/*:refs/tags/*' </code></pre> <p>Please note that the documentation prior to 1.8.0.3 was ambiguous about this aspect of "<code>fetch --tags</code>" behavior.<br> <a href="https://github.com/git/git/commit/f0cb2f137c6e399bab1be92c7cc8e3e08bd36c4f">Commit f0cb2f1</a> (2012-12-14) <code>fetch --tags</code> made the documentation match the old behavior.<br> This commit changes the documentation to match the new behavior (see <a href="https://github.com/git/git/blob/c5a84e92a2fe9e8748e32341c344d7a6c0f52a50/Documentation/fetch-options.txt#L63-L66"><code>Documentation/fetch-options.txt</code></a>).</p> <p>Request that all tags be fetched from the remote <strong>in addition to whatever else is being fetched</strong>.</p> </blockquote> <hr> <p>Since Git 2.5 (Q2 2015) <code>git pull --tags</code> is more robust:</p> <p>See <a href="https://github.com/git/git/commit/19d122bf1b119a759267076fead332fb857af87e">commit 19d122b</a> by <a href="https://github.com/pyokagan">Paul Tan (<code>pyokagan</code>)</a>, 13 May 2015.<br> <sup>(Merged by <a href="https://github.com/gitster">Junio C Hamano -- <code>gitster</code> --</a> in <a href="https://github.com/git/git/commit/cc77b996120c548fd52799eee28c802358e260a7">commit cc77b99</a>, 22 May 2015)</sup></p> <blockquote> <h2><code>pull</code>: remove <code>--tags</code> error in no merge candidates case</h2> <p>Since <a href="https://github.com/git/git/commit/441ed4131b2d735fea08e4f6277c12b13acebd53">441ed41</a> ("<code>git pull --tags</code>": error out with a better message., 2007-12-28, Git 1.5.4+), <code>git pull --tags</code> would print a different error message if <code>git-fetch</code> did not return any merge candidates:</p> <pre><code>It doesn't make sense to pull all tags; you probably meant: git fetch --tags </code></pre> <p>This is because at that time, <code>git-fetch --tags</code> would override any configured refspecs, and thus there would be no merge candidates. The error message was thus introduced to prevent confusion.</p> <p>However, since <a href="https://github.com/git/git/commit/c5a84e92a2fe9e8748e32341c344d7a6c0f52a50">c5a84e9</a> (<code>fetch --tags</code>: fetch tags <em>in addition to</em> other stuff, 2013-10-30, Git 1.9.0+), <code>git fetch --tags</code> would fetch tags in addition to any configured refspecs.<br> Hence, if any no merge candidates situation occurs, it is not because <code>--tags</code> was set. As such, this special error message is now irrelevant.</p> <p>To prevent confusion, remove this error message.</p> </blockquote> <hr> <p>With Git 2.11+ (Q4 2016) <code>git fetch</code> is quicker.</p> <p>See <a href="https://github.com/git/git/commit/5827a03545663f6d6b491a35edb313900608568b">commit 5827a03</a> (13 Oct 2016) by <a href="https://github.com/peff">Jeff King (<code>peff</code>)</a>.<br> <sup>(Merged by <a href="https://github.com/gitster">Junio C Hamano -- <code>gitster</code> --</a> in <a href="https://github.com/git/git/commit/9fcd14491d32d76c3533ba0b1dfe7cabf31fe852">commit 9fcd144</a>, 26 Oct 2016)</sup> </p> <blockquote> <h2><code>fetch</code>: use "quick" <a href="https://github.com/git/git/blob/5827a03545663f6d6b491a35edb313900608568b/sha1_file.c#L3223-L3245"><code>has_sha1_file</code></a> for tag following</h2> <p>When fetching from a remote that has many tags that are irrelevant to branches we are following, we used to waste way too many cycles when checking if the object pointed at by a tag (that we are not going to fetch!) exists in our repository too carefully.</p> <p>This patch teaches fetch to use HAS_SHA1_QUICK to sacrifice accuracy for speed, in cases where we might be racy with a simultaneous repack.</p> <p>Here are results from the included perf script, which sets up a situation similar to the one described above:</p> </blockquote> <pre><code>Test HEAD^ HEAD ---------------------------------------------------------- 5550.4: fetch 11.21(10.42+0.78) 0.08(0.04+0.02) -99.3% </code></pre> <p>That applies only for a situation where:</p> <blockquote> <ol> <li>You have a lot of packs on the client side to make <code>reprepare_packed_git()</code> expensive (the most expensive part is finding duplicates in an unsorted list, which is currently quadratic).</li> <li>You need a large number of tag refs on the server side that are candidates for auto-following (i.e., that the client doesn't have). Each one triggers a re-read of the pack directory.</li> <li>Under normal circumstances, the client would auto-follow those tags and after one large fetch, (2) would no longer be true.<br> But if those tags point to history which is disconnected from what the client otherwise fetches, then it will never auto-follow, and those candidates will impact it on every fetch.</li> </ol> </blockquote>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload