Re: v3 Debian source package formats

2008-10-03 Thread George Danchev
On Thursday 02 October 2008 20:33:00 Manoj Srivastava wrote: > On Thu, Oct 02 2008, George Danchev wrote: > > Quoting Manoj Srivastava <[EMAIL PROTECTED]>: --cut-- > > Nobody is comparing git with quilt, really. Obviously you are trying > > to compare different unit

Re: v3 Debian source package formats

2008-10-02 Thread George Danchev
Quoting Manoj Srivastava <[EMAIL PROTECTED]>: --cut-- > Well, You look at the public branches to see the divergence. and > if you think my repo does not match the sources (which is a trust > issue, I suppose), You'll have ot do whatever you need to, since > obviously you do not believe

Re: v3 Debian source package formats

2008-10-01 Thread George Danchev
On Wednesday 01 October 2008 22:07:12 Manoj Srivastava wrote: > On Wed, Oct 01 2008, George Danchev wrote: > > On Wednesday 01 October 2008 15:13:45 Manoj Srivastava wrote: > >> On Wed, Oct 01 2008, martin f krafft wrote: > >> > also sprach Manoj Srivastava <[E

Re: v3 Debian source package formats

2008-10-01 Thread George Danchev
On Wednesday 01 October 2008 15:13:45 Manoj Srivastava wrote: > On Wed, Oct 01 2008, martin f krafft wrote: > > also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.10.01.0302 +0200]: > >> This is a strawman, really. The options are not the giant big > >> diff vs quilt (equally horrible,

Re: extracting patches from the ancestry graph

2008-10-01 Thread George Danchev
On Wednesday 01 October 2008 17:54:24 Manoj Srivastava wrote: --cut-- > > 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,

Re: extracting patches from the ancestry graph

2008-10-01 Thread George Danchev
Quoting Manoj Srivastava <[EMAIL PROTECTED]>: > 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 f