gnu-arch-users
[Top][All Lists]
Advanced

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

[Gnu-arch-users] [BUG] microbranches: prism-merge vs multi-merge


From: Tom Lord
Subject: [Gnu-arch-users] [BUG] microbranches: prism-merge vs multi-merge
Date: Thu, 27 May 2004 11:42:37 -0700 (PDT)


Another use for the idea of "forking microbranches to make new
microbranches" is catching up after your upstream moves to a 
new branch.



    > X-Injected-Via-Gmane: http://gmane.org/
    > From: address@hidden (Julian T. J. Midgley)
    > Date: Thu, 27 May 2004 10:25:22 +0000 (UTC)
    > X-Complaints-To: address@hidden
    > X-Gmane-NNTP-Posting-Host: hanjague.menavaur.org
    > X-Newsreader: trn 4.0-test76 (Apr 2, 2001)
    > Originator: address@hidden (Julian T. J. Midgley)
    > X-BeenThere: address@hidden
    > X-Mailman-Version: 2.1.4
    > Precedence: list
    > List-Id: a discussion list for all things arch-ish 
<gnu-arch-users.gnu.org>
    > List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/gnu-arch-users>,
    >   <mailto:address@hidden>
    > List-Archive: <http://mail.gnu.org/pipermail/gnu-arch-users>
    > List-Post: <mailto:address@hidden>
    > List-Help: <mailto:address@hidden>
    > List-Subscribe: <http://mail.gnu.org/mailman/listinfo/gnu-arch-users>,
    >   <mailto:address@hidden>
    > Sender: address@hidden
    > X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mail.42inc.com
    > X-Spam-DCC: : 
    > X-Spam-Status: No, hits=-1.0 required=4.5 tests=BAYES_00 autolearn=ham 
    >   version=2.63
    > X-42email-MailScanner-Information: Please contact 
http://www.42inc.com/support.html for more information.
    > X-42email-MailScanner: Found to be clean
    > X-UIDL: 87ad0523d268cf5ceaa6f98ad84d558b
    > 
    > 
    > In article <address@hidden>,
    > Miles Bader  <address@hidden> wrote:
    > >Florian Weimer <address@hidden> writes:
    > >> Is there some fix to make the branches "micro" again?  If development
    > >> continues for some time, they wil accumulate patches from the upstream
    > >> branch, which means that branches aren't really *that* cheap.
    > >
    > >The `obvious' way would be to re-tag from the upstream branch instead of
    > >merging from it, but I've always been afraid to do this, as you always
    > >hear about problems with mixed commit/tag branches.
    > 
    > Or to have a tool for forking a new set of microbranches from the
    > latest revision of the devel branch (after the upstream merge) and
    > replay or star-merge the changes from the old microbranches into the
    > new ones.
    > 
    > This exchanges microbranch-bloat for branch proliferation, which seems
    > a little cleaner.
    > 
    > Julian
    > 
    > 
    > 
    > 
    > 
    > -- 
    > Julian T. J. Midgley                       http://www.xenoclast.org/
    > Cambridge, England.
    > PGP: BCC7863F FP: 52D9 1750 5721 7E58 C9E1  A7D5 3027 2F2E BCC7 863F
    > 
    > 
    > 
    > _______________________________________________
    > Gnu-arch-users mailing list
    > address@hidden
    > http://mail.gnu.org/mailman/listinfo/gnu-arch-users
    > 
    > GNU arch home page:
    > http://savannah.gnu.org/projects/gnu-arch/
    > 
    > 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]