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

[Thomas Lord]

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

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