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!"
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
