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

[Jeff King <peff@peff.net>]

On Thu, Jul 26, 2018 at 12:01:34PM -0700, Junio C Hamano wrote:

> Tejun Heo <tj@kernel.org> writes:
> 
> > I should have explained the use case better.
> 
> No, you did not need to.  I was not saying the feature is not useful.
> I was only saying that "explain where in the history X sits" command
> (i.e. "name-rev X" and "describe X") did not look like a good place
> to have that feature.

Just brainstorming a few reasons you might not want it tied to name-rev:

 - 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").

 - 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")

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.

-Peff