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

[Thomas Lord]

    > From: John Meinel <address@hidden>    > X-Accept-Language: en-us, en

    [about ./=merges]

    > I think the idea that the patch name gets kept, but you can optionally 
    > keep the patch-log itself is a good idea. So the '{arch}/=merged' file 
    > would contain the equivalent of
    > tla logs --merges

The ./=merges file records a version-specific history of the
application of two particular merge commands.  The merge commands
aren't built-in yet but could be: they are a special case of 
star-merge followed by one of two kinds of log pruning.

The contents of the ./=merges file is meaningless _unless_ the version
it is built for is managed as a mainline in the style of the process
spec I posted /and/ the versions merged into that mainline and
mentioned in =merges are one of the two kinds of submission version
described in the process spec.

So, no, the =merges file does not contain '--merges' data and doesn't
name any revisions merged in the patch-log from a submission version
with the sole exception of the highest numbered revision from the
submission version itself.

In other words, suppose that submission branch S contains logs for
versions S, T, U, and V.   We merge that into mainline M.   The S, T,
U, and V log additions are pruned from mainline and =merges is updated 
to mention the latest revision of S (which was just merged in).

-t