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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 7, 2008, 23:53 UTC
Message-ID: <7vhc8rjyxj.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080907103415.GA3139@cuci.nl>

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