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

From: Jeff King <peff@peff.net>
Date: Jul 27, 2018, 08:40 UTC
Message-ID: <20180727084039.GB11932@sigill.intra.peff.net>
In-Reply-To: <xmqqr2jpq0s1.fsf@gitster-ct.c.googlers.com>

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

Show 8 quoted lines

> 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