diff options
Diffstat (limited to 'devdocs/git/git-cherry.html')
| -rw-r--r-- | devdocs/git/git-cherry.html | 42 |
1 files changed, 42 insertions, 0 deletions
diff --git a/devdocs/git/git-cherry.html b/devdocs/git/git-cherry.html new file mode 100644 index 00000000..2a53f374 --- /dev/null +++ b/devdocs/git/git-cherry.html @@ -0,0 +1,42 @@ +<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] [<upstream> [<head> [<limit>]]]</pre> </div> </div> <h2 id="_description">Description</h2> <div class="sectionbody"> <p>Determine whether there are commits in <code><head>..<upstream></code> that are equivalent to those in the range <code><limit>..<head></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><limit>..<head></code>, prefixed with <code>-</code> for commits that have an equivalent in <upstream>, 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"> <upstream> </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"> <head> </dt> <dd> <p>Working branch; defaults to HEAD.</p> </dd> <dt class="hdlist1" id="Documentation/git-cherry.txt-ltlimitgt"> <limit> </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 <limit> 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"> + © 2012–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> |