Date: Thu, 28 Oct 2004 13:06:20 -0700 (PDT)
Message-Id: <200410282006.i9SK6Kk2086420@xl2.seyza.com>
From: Thomas Lord <lord@emf.net>
To: abentley@panoramicfeedback.com
In-reply-to: <41814B9E.5040601@panoramicfeedback.com> (message from Aaron
	Bentley on Thu, 28 Oct 2004 15:42:22 -0400)
Subject: Re: [Gnu-arch-users] Potential flaw in patch-log pruning in proposal
References: <20041025210724.GA19744@merconline.com>
	<200410272144.i9RLiYnd074868@xl2.seyza.com>
	<41803AEC.1050209@panoramicfeedback.com>
	<200410281727.i9SHRS8v084841@xl2.seyza.com>
	<41814B9E.5040601@panoramicfeedback.com>
Cc: gnu-arch-users@gnu.org
Precedence: list
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 2099
Lines: 60

    > From: Aaron Bentley <abentley@panoramicfeedback.com>

    > Thomas Lord wrote:
    > >     > From: Aaron Bentley <abentley@panoramicfeedback.com>

    > >     > One of the features of Arch I really like is the history-sensitive 
    > >     > merging.  This process breaks history-sensitive merge commands.

    > > That is a complete misapprehension.

    > No, that is totally accurate.  The process that Matthew Dempsky used to 
    > commit patch-7 breaks all conceivable history-based merge commands, and 
    > requires a human to determine its origins.

You're full of it.  The rather painstakingly produced draft process
spec and diagrams show why you are full of it and I'm left with the
impression that you just don't acknowledge that.


    > Now, if we assume the =merges idea is implemented, it may or may not be 
    > possible to fix the commands, 

Knock off that craziness.  =merges would automate a fairly esoteric
usage pattern for other commands, that's all.  It's not central to
implementing the process spec.


    > My current X is not maintained using star-merge, because 
    > lord@emf.net--2004/tla--devo--1.3 occasionally cherry-picked changes 
    > from me.  

But in the future the mainline won't behave in such an undisciplined
way so you'll be able to use star-merge just fine.  Of course, in
return, you have to offer your contributions as submission branches or
else trick some poor unwitting soul into doing that for you.

    > > You can star-merge from M freely.  That's the only thing that should
    > > ever change '=merges' (or we can make '=merges.$VERSION') in your
    > > tree.

    > I cannot star-merge from M freely, because I can't detect when M merges 
    > changes that originated in X.


X, not being a submission branch, is something that M will never merge
from.   Have you /actually read/ the process document?

-t


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/