Hello, Junio.
On Thu, Jul 26, 2018 at 08:12:45AM -0700, Junio C Hamano wrote:
> Tejun Heo <t...@kernel.org> writes:
>
> > From a6a88c3da252d69547ac8b463098fc4f4c03f322 Mon Sep 17 00:00:00 2001
> > From: Tejun Heo <t...@kernel.org>
> > Date: Thu, 26 Jul 2018 04:14:52 -0700
> > Subject: [PATCH] name_rev: add support for --cherry-picks
>
> The above belongs to the mail header, not the body.
Ah, right, sorry about that.
> > $ git name-rev --cherry-picks 10f7ce0a0e524279f022
> > 10f7ce0a0e524279f022 master~1
> > d433e3b4d5a19b3d29e2c8349fe88ceade5f6190 branch1
> > 82cddd79f962de0bb1e7cdd95d48b48633335816 branch2
> > 58a8d36b2532feb0a14b4fc2a50d587e64f38324 branch3
> > fa8b79edc5dfff21753c2ccfc1a1828336c4c070 branch4~1
>
> "git name-rev X" asks "I want to know about X". And the first line
> of the above tells us that 10f7ce is the first parent of the master
> branch. What does the second line tell us? 10f7ce was created by
> cherry picking d433e3b4 which sits at the tip of branch1?
>
> It appears that you are showing the reverse (d433e3, 58a8d3 and
> fa8b79 sit next to each other, but it cannot be that 10f7ce was
> created by cherry-picking these three). I do not mean to say that
So, it means that d433e, 58a8d and fa8b7 are created by cherry picking
10f7c and 72cdd is created by cherry picking d433e.
> the reverse information is not useful thing to learn about the
> commit (i.e. "X got cherry-picked to all these places") but I am
> having a hard time convincing myself that the feature sits well in
> "describe" and "name-rev".
I should have explained the use case better. Let's say I'm forking
off and maintaining prod releases. We branch it off of a major
upstream version and keeps developing / backporting on that branch
reguarly cutting releases. A lot of commits get cherry-picked back
from master tracking upstream but some are also cherry picked to
sub-release branches for quick-fix releases. e.g.
v4.16
o----o----o----A----o----o..........................................o master
\.----o----o....A'----o----o.................o v4.16-prod
\ \.----o----o v4.16-prod-r2
\ .----o----A'' v4.16-prod-r1
Given a commit, it's useful to find out through which version that got
released, which is where "git-describe --contains" helps. However,
when commits are backported through cherry-picks to prod branches as
in above, that commit is released through multiple versions and it's a
bit painful to hunt them down. This is what --cherry-picks helps
with, so if now I do "git describe --contains --cherry-picks A", it'll
tell me that...
Upstream, it's v4.17-rc1
Backported and released through v4.16-prod-r2
Also backported to v4.16-prod-r1 (cuz the fix happened while r1 was going
through rc's)
So, it extends the description of how the original commit is released
(or given name) so that releases through cherry-picks are also
included.
Thanks.
--
tejun
