From: Junio C Hamano <gitster@pobox.com>
To: Thomas Rast <tr@thomasrast.ch>
Cc: git@vger.kernel.org, a.huemer@commend.com,
"Michael S. Tsirkin" <mst@kernel.org>, Jeff King <peff@peff.net>
Subject: Re: [PATCH v2] Revamp git-cherry(1)
Date: Fri, 22 Nov 2013 11:25:57 -0800 [thread overview]
Message-ID: <xmqqa9gw1bne.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <dde93c10b7f6cb7b8cf94e9a0310c8e05aca2517.1385137650.git.tr@thomasrast.ch> (Thomas Rast's message of "Fri, 22 Nov 2013 17:29:16 +0100")
Thomas Rast <tr@thomasrast.ch> writes:
> NAME
> ----
> +git-cherry - Find commits not applied in upstream
>
> +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.
Thanks, this reads really much better than tha original.
We are listing those that need to be added to the upstream with "+",
while listing those that can be dropped from yours if you rebase
with "-". Hinting the rationale behind the choice of "+/-"
somewhere may help as a mnemonic to the readers (see below).
> +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`):
Perhaps we want a blank line before "Later, ..." to be consistent
with all the other displayed examples here (I'll squash it locally
before queuing), even though AsciiDoc seems to format this just
fine.
> +
> +------------
> +$ git fetch # update your notion of origin/master
> +$ git cherry -v
> +------------
> +
> +Concrete example
> +~~~~~~~~~~~~~~~~
"A concrete example", perhaps? I dunno.
> +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 been
> +applied:
It shows a concise summary of "what has yet to be applied" (to be
consistent with the one-line description in the NAME section).
> +------------
> +$ git cherry origin/master topic
> +- cccc000... commit C
> ++ bbbb000... commit B
> +- aaaa000... commit A
> +------------
And the earlier "why +/-" could be done after this picture,
perhaps like:
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`.
or somesuch?
next prev parent reply other threads:[~2013-11-22 19:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-21 11:30 [RFC PATCH] Revamp git-cherry(1) Thomas Rast
2013-11-21 11:54 ` Jeff King
2013-11-21 20:58 ` Thomas Rast
2013-11-21 19:26 ` Junio C Hamano
2013-11-21 21:02 ` Thomas Rast
2013-11-21 22:04 ` Junio C Hamano
2013-11-22 16:29 ` [PATCH v2] " Thomas Rast
2013-11-22 19:25 ` Junio C Hamano [this message]
2013-11-22 19:37 ` Thomas Rast
2013-11-22 19:39 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqa9gw1bne.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=a.huemer@commend.com \
--cc=git@vger.kernel.org \
--cc=mst@kernel.org \
--cc=peff@peff.net \
--cc=tr@thomasrast.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.