Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

git-cherry(1) [centos man page]

GIT-CHERRY(1)							    Git Manual							     GIT-CHERRY(1)

git-cherry - Find commits not merged upstream SYNOPSIS
git cherry [-v] [<upstream> [<head> [<limit>]]] DESCRIPTION
The changeset (or "diff") of each commit between the fork-point and <head> is compared against each commit between the fork-point and <upstream>. The commits are compared with their patch id, obtained from the git patch-id program. Every commit that doesn't exist in the <upstream> branch has its id (sha1) reported, prefixed by a symbol. The ones that have equivalent change already in the <upstream> branch are prefixed with a minus (-) sign, and those that only exist in the <head> branch are prefixed with a plus (+) symbol: __*__*__*__*__> <upstream> / fork-point \__+__+__-__+__+__-__+__> <head> If a <limit> has been given then the commits along the <head> branch up to and including <limit> are not reported: __*__*__*__*__> <upstream> / fork-point \__*__*__<limit>__-__+__> <head> Because git cherry compares the changeset rather than the commit id (sha1), you can use git cherry to find out if a commit you made locally has been applied <upstream> under a different commit id. For example, this will happen if you're feeding patches <upstream> via email rather than pushing or pulling commits directly. OPTIONS
-v Verbose. <upstream> Upstream branch to compare against. Defaults to the first tracked remote branch, if available. <head> Working branch; defaults to HEAD. <limit> Do not report commits up to (and including) limit. SEE ALSO
git-patch-id(1) GIT
Part of the git(1) suite Git 06/10/2014 GIT-CHERRY(1)

Check Out this Related Man Page

GIT-REQUEST-PULL(1)                                                 Git Manual                                                 GIT-REQUEST-PULL(1)

git-request-pull - Generates a summary of pending changes SYNOPSIS
git request-pull [-p] <start> <url> [<end>] DESCRIPTION
Generate a request asking your upstream project to pull changes into their tree. The request, printed to the standard output, begins with the branch description, summarizes the changes and indicates from where they can be pulled. The upstream project is expected to have the commit named by <start> and the output asks it to integrate the changes you made since that commit, up to the commit named by <end>, by visiting the repository named by <url>. OPTIONS
-p Include patch text in the output. <start> Commit to start at. This names a commit that is already in the upstream history. <url> The repository URL to be pulled from. <end> Commit to end at (defaults to HEAD). This names the commit at the tip of the history you are asking to be pulled. When the repository named by <url> has the commit at a tip of a ref that is different from the ref you have locally, you can use the <local>:<remote> syntax, to have its local name, a colon :, and its remote name. EXAMPLE
Imagine that you built your work on your master branch on top of the v1.0 release, and want it to be integrated to the project. First you push that change to your public repository for others to see: git push https://git.ko.xz/project master Then, you run this command: git request-pull v1.0 https://git.ko.xz/project master which will produce a request to the upstream, summarizing the changes between the v1.0 release and your master, to pull it from your public repository. If you pushed your change to a branch whose name is different from the one you have locally, e.g. git push https://git.ko.xz/project master:for-linus then you can ask that to be pulled with git request-pull v1.0 https://git.ko.xz/project master:for-linus GIT
Part of the git(1) suite Git 2.17.1 10/05/2018 GIT-REQUEST-PULL(1)
Man Page