Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal

[Thomas Lord]

    > From: Matthew Dempsky <address@hidden>

    > Thomas Lord <address@hidden> writes:

    > >     > From: Matthew Dempsky <address@hidden>

    > >     > One other thing to consider about merging submission branches is 
that
    > >     > they all add a CONTRIBUTION-LOG file which would surely conflict
    > >     > unless you made sure to delete this after merging.
    > >
    > >     > (Whether to interpret this as a problem with the proposal or the 
idea
    > >     > of development lines merging submission branches I'm not sure 
about
    > >     > yet.)

    > > It's deliberate.   The merging you do to merge a submission branch is,
    > > in effect, a higher-level merge command than ordinary 'star-merge'.
    > > You have to deal with 'CONTRIBUTION-LOG' and with pruning patch logs.
    > > Eventually, this higher-level command should be built-in to 'tla' but,
    > > for now, please just write yourself a little shell script.

    > Right, I am using a script to automate that part.

    > In that email, however, I was referring to people who are simply
    > updating their trees (e.g. jblack, abentley, etc.) wrt the submission
    > branches that have been merged into mainline now.  They would want to
    > be able to star-merge or replay those branches as well in case any
    > changes were made in the submission branch (patch fixes or conflict
    > resolution stuff).

Nah.  Submission branches are (revisioned) changesets against a
well-defined mainline.  That implies some constraints on how a
submission branch is sanely used.   If they want something that is
'mainling + some-unmerged-submission-branches' they can constuct such
an entity by paying attention to '=merges'.

Submission branches are just versioned changesets.  People shouldn't
be so scared of them.   (Bwahaha :-)

-t