How to cope with patches sanely

[Manoj Srivastava]

On Fri, 29 Feb 2008 12:35:30 +1300, Sam Vilain <sam at vilain.net> said: 

> Manoj Srivastava wrote:
>>> Feature branches don't magically allow you to avoid merge conflicts
>>> either, so this is a red herring. Once you've resolved the conflict,
>>> then it becomes just another change. This change can become a diff
>>> in a stack of diffs.
>> 
>> This whole message is a red herring, since hte feature branches do
>> not attempt to handle merge conflicts -- that is not their purpose.
>> They capture one single feature, independently from every other
>> feature, and thumb their collective noses at merge conflicts.

> Yes.  Feature branches are effectively forking a particular version of
> a project - this is not a problem, and is essential for efficient
> development.  People jumbling together changes in "trunk" branches is
> perhaps one of the worst upshots of the 2002-2006 or so obsession with
> poorly designed centralised systems and in my opinion sank many
> projects.

        Err. If you go back and read this thread in the archive, You'll
 note that I have stated that my feature branches are always kept up to
 date with the latest upstream branch I am basing my Debian package
 on. 

        When I have been creating patches for inclusion with upstream, I
 essentially feed them the source patch and a changelog entry --
 essentially, creating a single patch series; squashing the underlying
 history.  Most upstream do not care about the messy history of my
 development; and most do not grok arch well enough to pull directly.

        I am not sure what the relevance of trunk changes you mention
 has to the current thread.

>> The history of the integration branch captures the integration
>> effort; and the integration branch makes no effort to keep the
>> integration work up to date with current upstream and feature
>> branches.

> Initially perhaps.  However, once a feature is considered ready for
> inclusion, it is important that it contains merges FROM the branch
> they are targetting.

        Please do read the thread history.  The feature branches being
 kept updated with the upstream branch means that my feature branches
 _always_ apply to the current upstream.

> They mean that a later merge back the other way, to merge the feature
> branch into the target branch, can happen painlessly.  ASSUMING that
> you're using a system which has commutative merge characteristics,
> such as git or mercurial.

        I use Arch.

>> If you think you can extract an up to date integration patch from the
>> entrails of the integration branch -- feel free o smack me down.  But
>> please provide some substance to the assertion that it is doable.

> Perhaps I missed the context to this discussion - certainly expressing

        I think you have.

> a history containing merge nodes in patches is non-trivial and can't
> be done with standard patch format - but I believe that this is
> certainly possible.

        Great. Show me the code. My arch repo is publicly available on
 arch.debian.org.   As they say in Missouri, Show me.

> Can you express this problem with reference to a particular history of
> an integration branch?  I will provide some short git commands to
> extract the information in the form you are after.

 http://arch.debian.org/cgi-bin/archzoom.cgi/srivasta@debian.org--lenny?color=sunny?expand

        Take any package. Say, flex. Or flex-old. You have all my
 feature branches there. The --devo branch is the integration branch.
 Please show me an automated way you can grab the feature branches and
 generate a quilt series that gives you the devo branch.  The diff.gz is
 how we get from upstream to the devo branch (modulo ./debian); if you
 can break that down nicely for the folks who want each feature
 separate, that would work as well.

        If you code works well enough every single time a new upstream
 comes around and I release a new version of flex or whatever,  I'll
 throw in the generated quilt patches.

        Until then, could people stop telling me how easy it is to
 automatically generate quilt series for my packages, and that I should
 jut shut up and code it and not stand in the way of other people trying
 to make such quilt series generation the standard way of doing source
 packages?

        BTW, I have heard no one comment on my offer to generate a pure
 patch for each feature branch, with no warranty that the patches can be
 applied linearly, along with the diff.gz that defines the integration
 branch, so that a human can probably tell what most of the changes mean
 (which is what people seemed to be after with neatly separated out
 patches).

        manoj
 who does not think that one can go easily from a set of independent
 pure feature patches that separately apply to upstream to a quilt
 series programmatically
-- 
Did I do an INCORRECT THING??
Manoj Srivastava <srivasta at debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C