Re: [PATCH v2] name_rev: add support for --cherry-picks

[Tejun Heo <tj@kernel.org>]

Hello, Junio.

On Thu, Jul 26, 2018 at 08:12:45AM -0700, Junio C Hamano wrote:
> Tejun Heo <tj@kernel.org> writes:
> 
> > From a6a88c3da252d69547ac8b463098fc4f4c03f322 Mon Sep 17 00:00:00 2001
> > From: Tejun Heo <tj@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