[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to handle Debian patches

On Fri, 16 May 2008 15:49:25 -0700, Russ Allbery <rra@debian.org> said: 

> Manoj Srivastava <srivasta@debian.org> writes:
>> Create a submission branch. There are two audiences for your work;
>> one is downstream (which includes the integration branch for Debian),
>> the other is upstream, one audience does not like rebases, the other
>> thrives on it. See
>> http://www.golden-gryphon.com/software/misc/packaging.html#sec-5.4>  for
>> http://www.golden-gryphon.com/software/misc/packaging.html#sec-5.4>  details
>> http://www.golden-gryphon.com/software/misc/packaging.html#sec-5.4>  on
>> http://www.golden-gryphon.com/software/misc/packaging.html#sec-5.4>  this
>> http://www.golden-gryphon.com/software/misc/packaging.html#sec-5.4>  scheme.

> Oh, huh.  Both rebase *and* merge.  I didn't even think of that.

> That would work, although it does... well, not double, but at least
> increase the work for any branch that also has a submission branch,
> since any upstream merge conflicts have to be resolved on both
> branches.  Or is there some way to reuse the resolution work done with
> one of those branches when rebasing/merging the other?

        You can mostly automate this, with proper naming. (I suppose I
 should blog about this). See, my topic branches are called topic--foo,
 and there is a corresponding submission--foo branch.

        Whenever you commit to the topic--foo branch, arrange to cherry
 pick that commit to the submission--foo branch.

        When you merge upstream into topic--foo branch, you also rebase
 submission--foo branch. Sure, you might at times have to resolve the
 same changes in both branches, but doing it one after the other, you
 can just copy the affected files into the stash, or something, and just
 pull them out after -- so one set of cp/cp back per file, and this is
 also not a major amount of work.

        I still need to write more general scaffold scripts, but this is
 working out rather well.

Computers will not be perfected until they can compute how much more
than the estimate the job will cost.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: