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

[Aaron Bentley]

Thomas Lord wrote:
>     > From: Aaron Bentley <address@hidden>
>
>     > Thomas Lord wrote:
>     > >     > From: Aaron Bentley <address@hidden>
>
>     > >     > 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 
address@hidden/tla--devo--1.2--patch-25 and 
address@hidden/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 
>     > address@hidden/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.