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

["Stephen R. van den Berg" <srb@cuci.nl>]

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