From: Stephen R. van den Berg Date: Wed, 10 Sep 2008 00:13:16 GMT Subject: Re: [RFC] origin link for cherry-pick and revert 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!"