Message-ID: <418156C2.3010506@panoramicfeedback.com>
Date: Thu, 28 Oct 2004 16:29:54 -0400
From: Aaron Bentley <abentley@panoramicfeedback.com>
User-Agent: Mozilla Thunderbird 0.5 (X11/20040309)
MIME-Version: 1.0
To: Thomas Lord <lord@emf.net>
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>
	<200410282006.i9SK6Kk2086420@xl2.seyza.com>
In-Reply-To: <200410282006.i9SK6Kk2086420@xl2.seyza.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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: 2904
Lines: 80
Thomas Lord wrote:
>     > 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.

Unless you can demonstrate that the information is not lost, *you're* 
full of it.  If there's no history, there can't be history-based commands.

Tell me exactly how I can determine that patch-7 is derived from 
jblack@gnuarch.org--2004/tla--devo--1.2--patch-25 and 
aaron.bentley@utoronto.ca--tla-2004/tlasrc--devel--0.2--patch-22 without 
recource to human intelligence.

> 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.

It doesn't matter how much effort was spent, it matters whether it's a 
good idea.  You can either demonstrate that the information is not lost, 
or not.  I'm betting not.

>     > 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.

So we break the existing commands, say =merges is a solution, and then 
don't support =merges?  I must be reading that wrong.

>     > 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.

As I said, if I offer submission branches, they'll still be derived from X.

> X, not being a submission branch, is something that M will never merge
> from.   

Not directly.  That's why I argue that it's important to keep track of 
indirect merges.

Have you /actually read/ the process document?

Yes, I've read the process draft.  I can't say I enjoyed it, or that all 
of it was intelligible.

Aaron

-- 
Aaron Bentley
Director of Technology
Panometrics, Inc.


_______________________________________________
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/