extracting patches from the ancestry graph

[Manoj Srivastava]

On Wed, Oct 01 2008, George Danchev wrote:

> Quoting Manoj Srivastava <srivasta at acm.org>:
>
>> On Wed, Oct 01 2008, martin f krafft wrote:
>>
>>
>>> Assuming we have a number of feature branches, we may well have to
>>> resolve conflicts among them, so an integration branch seems like
>>> the right way forward. So unless we just build the package from the
>>> integration branch to produce a monolithic patch, your algorithm is
>>> something to focus on! I am still not convinced that it is possible
>>> to extract historic patches from the ancestry of a tag on the
>>> integration branch, but I'd love to be proven wrong! Unfortunately,
>>> I won't be able to look into this again before next week.
>>
>>         Slightly off topic, but there are other reasons to have a real,
>>  published integration branch. People who do not use the 3.0 (quilt)
>>  source package format and dpkg, for instance, people browsing the repo,
>>  will not have the automagic conversion of the quilt series into code
>>  the package is built from. If the integration branch is published, even
>>  casual browsers of code can see what the package did.
>
> Publishing your integration branch is nice, but you have made too many  
> naive assumptions here:
>
> 1) people do not need quilt nor dpkg to view and apply these patches

        I find it easier reading code than reading patches upon patches
 upon patches that modify code I can read. If there are dependent
 patches, keeping all the previous changes in your head as you look at
 yet another patch modofying the same file .. well, good luck.

        I do not think this is a naive assumption on my part. On the
 contrary. 

> 2) there is no guarantee that what you have in your publicly browsable
>    integration branch is actually what buildd are fed with to produce
>    the binary packages users use and are interested in changes done.

        You can easily check the integration branch in the repo versus
 the unpackahed sources (applying the giant diff.gz).  This is not
 really an argument that gells with me. Heck, I don't know if what is in
 Linus' release branch is what is in the tarball, but I don't thinkit
 bothers me a lot.

> 3) you are leaving non-internetworked users in the cold, but Debian  
> operates in such places.

        Hey, with the 3.0 (git+) format, we can bring these people
 in. But in this day and ag, the arguments for distributed VCS's and
 distributed development trump catering to the connectivity challenged.

        manoj
-- 
Speer's 1st Law of Proofreading: The visibility of an error is inversely
proportional to the number of times you have looked at it.
Manoj Srivastava <srivasta at acm.org> <http://www.golden-gryphon.com/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C