removing all downloaded devdocs files

1 files changed, 0 insertions, 42 deletions

diff --git a/devdocs/git/git-cherry.html b/devdocs/git/git-cherry.html
deleted file mode 100644
index 2a53f374..00000000
--- a/devdocs/git/git-cherry.html
+++ /dev/null
@@ -1,42 +0,0 @@
-<h1>git-cherry</h1>  <h2 id="_name">Name</h2> <div class="sectionbody">  <p>git-cherry - Find commits yet to be applied to upstream</p>  </div>   <h2 id="_synopsis">Synopsis</h2> <div class="sectionbody"> <div class="verseblock"> <pre class="content" data-language="shell">git cherry [-v] [&lt;upstream&gt; [&lt;head&gt; [&lt;limit&gt;]]]</pre> </div> </div>   <h2 id="_description">Description</h2> <div class="sectionbody">  <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>   <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">git-cherry-pick[1]</a>, <a href="git-am">git-am[1]</a> or <a href="git-rebase">git-rebase[1]</a>.</p>   <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>   <h2 id="_options">Options</h2> <div class="sectionbody"> <div class="dlist"> <dl> <dt class="hdlist1" id="Documentation/git-cherry.txt--v"> -v </dt> <dd> <p>Show the commit subjects next to the SHA1s.</p> </dd> <dt class="hdlist1" id="Documentation/git-cherry.txt-ltupstreamgt"> &lt;upstream&gt; </dt> <dd> <p>Upstream branch to search for equivalent commits. Defaults to the upstream branch of HEAD.</p> </dd> <dt class="hdlist1" id="Documentation/git-cherry.txt-ltheadgt"> &lt;head&gt; </dt> <dd> <p>Working branch; defaults to HEAD.</p> </dd> <dt class="hdlist1" id="Documentation/git-cherry.txt-ltlimitgt"> &lt;limit&gt; </dt> <dd> <p>Do not report commits up to (and including) limit.</p> </dd> </dl> </div> </div>   <h2 id="_examples">Examples</h2> <div class="sectionbody"> <div class="sect2"> <h3 id="_patch_workflows">
-Patch workflows</h3>  <p>git-cherry is frequently used in patch-based workflows (see <a href="gitworkflows">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 class="listingblock"> <div class="content"> <pre data-language="shell-session">$ git checkout -b topic origin/master
-# work and create some commits
-$ git format-patch origin/master
-$ git send-email ... 00*</pre> </div> </div>  <p>Later, you can see whether your changes have been applied by saying (still on <code>topic</code>):</p>  <div class="listingblock"> <div class="content"> <pre data-language="shell-session">$ git fetch  # update your notion of origin/master
-$ git cherry -v</pre> </div> </div> </div> <div class="sect2"> <h3 id="_concrete_example">
-Concrete example</h3>  <p>In a situation where topic consisted of three commits, and the maintainer applied two of them, the situation might look like:</p>  <div class="listingblock"> <div class="content"> <pre data-language="shell-session">$ 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</pre> </div> </div>  <p>In such cases, git-cherry shows a concise summary of what has yet to be applied:</p>  <div class="listingblock"> <div class="content"> <pre data-language="shell-session">$ git cherry origin/master topic
-- cccc000... commit C
-+ bbbb000... commit B
-- aaaa000... commit A</pre> </div> </div>  <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 class="sect2"> <h3 id="_using_a_limit">
-Using a limit</h3>  <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 class="listingblock"> <div class="content"> <pre data-language="shell-session">$ 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</pre> </div> </div>  <p>By specifying <code>base</code> as the limit, you can avoid listing commits between <code>base</code> and <code>topic</code>:</p>  <div class="listingblock"> <div class="content"> <pre data-language="shell-session">$ git cherry origin/master topic base
-- cccc000... commit C
-+ bbbb000... commit B
-- aaaa000... commit A</pre> </div> </div> </div> </div>   <h2 id="_see_also">See also</h2> <div class="sectionbody">  <p><a href="git-patch-id">git-patch-id[1]</a></p>  </div><div class="_attribution">
-  <p class="_attribution-p">
-    &copy; 2012&ndash;2024 Scott Chacon and others<br>Licensed under the MIT License.<br>
-    <a href="https://git-scm.com/docs/git-cherry" class="_attribution-link">https://git-scm.com/docs/git-cherry</a>
-  </p>
-</div>