Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
- From
Sam Vilain <sam@vilain.net>
- Date
- May 1, 2006, 01:25 UTC
- Message-ID
- <4455638A.3070802@vilain.net>
- In-Reply-To
- <7v8xpmva9x.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
Show 24 quoted lines
>>We can fast-forward if (1) you pulled from "pu" the last time, >>and (2) you haven't added anything on top of it on your own, and >>(3) you pull from "pu" again, if the previous "pu" (i.e. your >>"pu") is a parent of the updated "pu". We do not need "prior" >>for that. The old "pu" being _one_ _of_ the parents, not even >>necessarily be the first one, would do just fine. >> >> > >This part may want a bit more elaboration. > >Often, we see in the Linus kernel tree a fast forward of his tip >from a recent commit Linus made to bunch of networking commits >made by David S Miller. For example, Linus fast forwarded to >18118c from David's tree before making this commit: > [...] >To David, the commits he has in the chain between 6b426e to >18118c obviously suited the purpose of his tree better, and that >was why these commits were made. And the fact Linus fast >forwarded to the tip of David is an implicit statement by Linus >that that results suits the purpose of Linus tree better as well >compared to his old tip, presumably 6b426e. > >
Aha, now I see reason in the madness. So, the "prior" head is not stored in the trees, and tracking the progress of actual head transitions is loosely defined / a research topic. But demonstrably derivable. That works for me.
Sam.