On Thu, Jul 26, 2018 at 12:01:34PM -0700, Junio C Hamano wrote:
> Tejun Heo <t...@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
