Re: [RFC] cherry-pick using multiple parents to implement -x

[Junio C Hamano <gitster@pobox.com>]

"Stephen R. van den Berg" <srb@cuci.nl> writes:

> - And depending on an affirmative on the previous question, would it be
>   acceptable to teach the gitk preceding/following tag listing to deal
>   with these backport/forwardports ?

Even though the answer to "the previous question" is a solid no, it is not
just acceptable but it would be very useful to teach gitk that the commit
you cherry-picked from is somehow related to the resulting commit from the
cherry-picking, and teach it to give you an easy access (and even a visual
cue about their relationship) to the other commit when it is showing the
cherry-picked commit.

I think the commit object name -x records in the commit message of the
cherry-picked one is noticed by gitweb to give you an easy access.  You
could teach gitk a similar trick, and that would not just help cherry
picking but also reverts, and a fix-up commit that says "This fixes the
regression introduced by commit 90ff09a5".

You could further draw _different_ kind of line on the upper "graph" pane,
to show that a commit is _related_ to another commit.  Because cherry-pick
relation is about the resulting commit and the _single_ commit that was
cherry-picked (in other words, the parent of the cherry-picked original
does not have _any_ relation to the commit that results from the
cherry-pick), such a line should be visually very distinct from the usual
parent-child relationship, which is the gitk graph (or any other commit
ancestry graph) is about.  But if it can be represented clearly, I'd
imagine that it would be interesting to see.