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

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

Jeff King <peff@peff.net> writes:

> And yes, you can get _too_ general to the point where your semantics
> become meaningless. But I don't think that is the case here. You are
> defining the origin field as "by the way, the difference between state X
> and state Y was used to make this commit". cherry-pick just happens to
> make Y=X^, but something like rebase could use a series.
>
> As for "git vs changeset": this is git. So you have a sequence of tree
> states whether that is what you want or not. Thus you are specifying
> the difference between _some_ pair of commits. I don't see any benefit
> to restricting it to a commit and one of its parents.

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

Not only that, it is not just "the difference between state X and Y" that
you used to come to that tree.  Another thing that is involved is the
specific cherry-pick implementation back when the commit was made.  That
was what gave you the tree.

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

After reading the discussion so far, I am still not convinced if this is a
good idea, nor this time around it is that much different from what the
previous "prior" link discussion tried to do.