145 lines
		
	
	
	
		
			3.5 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
			
		
		
	
	
			145 lines
		
	
	
	
		
			3.5 KiB
		
	
	
	
		
			Text
		
	
	
	
	
	
| git-cherry(1)
 | |
| =============
 | |
| 
 | |
| NAME
 | |
| ----
 | |
| git-cherry - Find commits yet to be applied to upstream
 | |
| 
 | |
| SYNOPSIS
 | |
| --------
 | |
| [verse]
 | |
| 'git cherry' [-v] [<upstream> [<head> [<limit>]]]
 | |
| 
 | |
| DESCRIPTION
 | |
| -----------
 | |
| Determine whether there are commits in `<head>..<upstream>` that are
 | |
| equivalent to those in the range `<limit>..<head>`.
 | |
| 
 | |
| 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 linkgit:git-cherry-pick[1], linkgit:git-am[1] or
 | |
| linkgit:git-rebase[1].
 | |
| 
 | |
| Outputs the SHA1 of every commit in `<limit>..<head>`, prefixed with
 | |
| `-` for commits that have an equivalent in <upstream>, and `+` for
 | |
| commits that do not.
 | |
| 
 | |
| OPTIONS
 | |
| -------
 | |
| -v::
 | |
| 	Show the commit subjects next to the SHA1s.
 | |
| 
 | |
| <upstream>::
 | |
| 	Upstream branch to search for equivalent commits.
 | |
| 	Defaults to the upstream branch of HEAD.
 | |
| 
 | |
| <head>::
 | |
| 	Working branch; defaults to HEAD.
 | |
| 
 | |
| <limit>::
 | |
| 	Do not report commits up to (and including) limit.
 | |
| 
 | |
| EXAMPLES
 | |
| --------
 | |
| 
 | |
| Patch workflows
 | |
| ~~~~~~~~~~~~~~~
 | |
| 
 | |
| git-cherry is frequently used in patch-based workflows (see
 | |
| linkgit:gitworkflows[7]) 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:
 | |
| 
 | |
| ------------
 | |
| $ git checkout -b topic origin/master
 | |
| # work and create some commits
 | |
| $ git format-patch origin/master
 | |
| $ git send-email ... 00*
 | |
| ------------
 | |
| 
 | |
| Later, you can see whether your changes have been applied by saying
 | |
| (still on `topic`):
 | |
| 
 | |
| ------------
 | |
| $ git fetch  # update your notion of origin/master
 | |
| $ git cherry -v
 | |
| ------------
 | |
| 
 | |
| Concrete example
 | |
| ~~~~~~~~~~~~~~~~
 | |
| 
 | |
| In a situation where topic consisted of three commits, and the
 | |
| maintainer applied two of them, the situation might look like:
 | |
| 
 | |
| ------------
 | |
| $ 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
 | |
| ------------
 | |
| 
 | |
| In such cases, git-cherry shows a concise summary of what has yet to
 | |
| be applied:
 | |
| 
 | |
| ------------
 | |
| $ git cherry origin/master topic
 | |
| - cccc000... commit C
 | |
| + bbbb000... commit B
 | |
| - aaaa000... commit A
 | |
| ------------
 | |
| 
 | |
| Here, we see that the commits A and C (marked with `-`) can be
 | |
| dropped from your `topic` branch when you rebase it on top of
 | |
| `origin/master`, while the commit B (marked with `+`) still needs to
 | |
| be kept so that it will be sent to be applied to `origin/master`.
 | |
| 
 | |
| 
 | |
| Using a limit
 | |
| ~~~~~~~~~~~~~
 | |
| 
 | |
| 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:
 | |
| 
 | |
| ------------
 | |
| $ 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
 | |
| ------------
 | |
| 
 | |
| By specifying `base` as the limit, you can avoid listing commits
 | |
| between `base` and `topic`:
 | |
| 
 | |
| ------------
 | |
| $ git cherry origin/master topic base
 | |
| - cccc000... commit C
 | |
| + bbbb000... commit B
 | |
| - aaaa000... commit A
 | |
| ------------
 | |
| 
 | |
| 
 | |
| SEE ALSO
 | |
| --------
 | |
| linkgit:git-patch-id[1]
 | |
| 
 | |
| GIT
 | |
| ---
 | |
| Part of the linkgit:git[1] suite
 |