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

From: Tejun Heo <tj@kernel.org>
Date: Jul 27, 2018, 14:47 UTC
Message-ID: <CAOS58YNjyLLDLpoDDB=oAKn3P_FLLD2WZrygBy6J+TV=E480NQ@mail.gmail.com>
In-Reply-To: <20180727084039.GB11932@sigill.intra.peff.net>

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?

Show 10 quoted lines

> 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