Re: [RFC] origin link for cherry-pick and revert

From: Stephen R. van den Berg <srb@cuci.nl>
Date: Sep 10, 2008, 00:13 UTC
Message-ID: <20080910001316.GF7459@cuci.nl>
In-Reply-To: <7vljy159v7.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:

>As for "by the way ... was used to make this commit": this is git.  So how
>you arrived at the tree state you record in a commit *does not matter*.

The typical use case for the origin links is in a project with several long-lived branches which use cherry-picks to backport amongst them. There is no real other way to solve this case, except for some rather kludgy stuff in the free-form commit message which doesn't mesh well with rebase/filter-branch/stgit etc.

As to "does not matter": then why does git store parent links?

>To my ears, it rhymes rather well with a famous quote from $gmane/217:

>    You're freezing your (crappy) algorithm at tree creation time, and
>    basically making it pointless to ever create something better later,
>    because even if hardware and software improves, you've codified that
>    "we have to have crappy information".

I tried to accomodate this approach by overloading the parent link and then making git more intelligent to figure out if it is a cherry-pick or not. That was deemed undesirable, so using the origin links is the next best thing (IMHO).

>good idea, nor this time around it is that much different from what the
>previous "prior" link discussion tried to do.

It is well-defined this time, and doesn't bleed across fetch/pull.

-- 
Sincerely,
           Stephen R. van den Berg.

"Be spontaneous!"