extracting patches from the ancestry graph

[George Danchev]

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
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.
3) you are leaving non-internetworked users in the cold, but Debian  
operates in such places.