Re: [PATCH v2] name_rev: add support for --cherry-picks
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jul 26, 2018, 15:12 UTC
- Message-ID
- <xmqqa7qerpxu.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <20180726143930.GW1934745@devbig577.frc2.facebook.com>
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.
Show 11 quoted lines
> It's often useful to track cherry-picks of a given commit. Add > --cherry-picks support to git-name-rev. When specified, name_rev also > shows the commits cherry-picked from the listed target commits with > indentations. > > $ 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 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".
Show 11 quoted lines
> Note that branch2 is further indented because it's a nested cherry > pick from d433e3b4d5a1. > > "git-describe --contains" is a wrapper around git-name-rev. Also add > --cherry-picks support to git-describe. > > v2: - Remove a warning message for a malformed cherry-picked tag. > There isn't much user can do about it. > - Continue scanning cherry-pick tags until a working one is found > instead of aborting after trying the last one. It might miss > nesting but still better to show than miss the commit entirely.