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

[Tejun Heo <tj@kernel.org>]

Hello, Jeff.

On Fri, Jul 27, 2018 at 4:47 AM Jeff King <peff@peff.net> wrote:
>  - the set of names might be distinct from the set of commits you'd want
>    to traverse.  For instance, you might want to use "name-rev --tags",
>    but find cherry-picks even on untagged branches (e.g., "--all").

Hmm... maybe but when I'm using --tags, I'm usually asking "when did
this get released?" and --cherry-picks seems to logically extend that
and fits such scenarios pretty well. ie. "Give me the release name and
all the aliases for this commit". We can play with the options to
support combinations of tagged/untagged but I'm not quite sure about
the usefulness. After all, calling the program twice isn't all that
difficult.

>  - instead of naming commits, you might want to see the information as
>    you are viewing git-log output ("by the way, this was cherry-picked
>    elsewhere, too")

name-rev --stdin sort of does this for commit names. I thought about
adding the support for --cherry-picks too but wasn't sure how to weave
in the result, but if we can figure that out this should work, right?

> So I kind of wonder if it would be more useful to have a command which
> incrementally updates a git-notes tree to hold the mapping, and then
> learn to consult it in various places. "git log --notes=reverse-cherry"
> would show it, though it might be worth teaching the notes-display code
> that certain types of notes contain object ids (so it would be
> interesting to recursively show their notes, or format them nicely,
> etc).
>
> I dunno. That is perhaps over-engineering. But it feels like
> "reverse-map the cherry-picks" is orthogonal to the idea of name-rev.

Hmm... to me, it makes logical sense because "name this commit" and
"also include aliases" seem to be a natural combination both in
semantics and use cases, but if there are better ways of tracking down
cherry-picks, I'm all ears.

Thanks.

-- 
tejun