On Fri, 29 Feb 2008 12:35:30 +1300, Sam Vilain <[EMAIL PROTECTED]> 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
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
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
> 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.
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
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
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
Did I do an INCORRECT THING??
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
vcs-pkg-discuss mailing list