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

[Thomas Lord]

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

Rather, this process relies on history-sensitive merges that aren't
yet built-in, but which are minor variations on merge commands which
are built in.   Adding a ./=merges file would be a step towards
automating this (rather trivial) style of merging.

Suppose (just as a straw-man, for the sake of argument) we have three
file:

  =merges
   The list of submission versions that have been merged
  =pending
   The list of submission versions that are "in the queue"
  =cherries (not in the mainline, only in your branches from the mainline)
   The subset of =pending that you like to keep in your tree

The set difference of =cherries and =merges gives you a list of
versions to star-merge into your tree if you want to be cherry-picking
ahead of mainline.   

Let's suppose that I have a mainline, M, and maintain =merges and
=pending.   You have an experimental branch X.

X is maintained by:

  1. Periodically star-merging from M

  2. Periodically star-merging from each version in the
     set difference of =cherries and =merges

  3. Arbitrary, other, X-specific changes

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.

You can star-merge from any version in =cherries freely, so long as
that version is not also named in =merges: so, perhaps a new
star-merge option for that.

Your other changes can be pretty free form.

You might want to take advantage of the log pruning of mainline so you
can log-prune your version X, too.  That's a little bit tricky because
there's no particular telling how a given patch log entry wound up in
X: whether it came from cherry-picking pending submission versions
(and hence can be pruned when those submission versions are merged
into mainline) or whether it came from the "free form" merging you're
also able to do into X.

So, I think you have to pick your community.  May as well make it yet
another file that lives only in your version:

        ./=community
           A list of log version, branche, categorie, and archive
           regexps of parts of the patch log tree to /not/ prune

and you can "inherit" the mainline M's log pruning by wiping your
X tree patch-log of everything not in '=community' and then
'sync-tree'ing with X.

No intentionally-recorded history is lost in this set-up: your X
version is perfectly fine.  At the same time, patch-tree log sizes in
the mainline can be kept to a bounded size.  (The problem of unbounded
growth has then shifted from patch-log size to the size of the
'=pending' file but that's both easy to solve /and/ not even worth
implementing a solution for for years and years (witness the
non-necessity of (conventional) ChangeLog pruning:  rotation: yes;
pruning: not so much.).


-t