Re: [Gnu-arch-users] Star merging with 3 branches

[Joshua Haberman]

On Tue, 2003-12-09 at 15:08, Tom Lord wrote:
>     > From: Joshua Haberman <address@hidden>
>     > Why is "subtracting out" required?  The changesets that already exist in
>     > smallfeatures and its ancestors contain information at enough
>     > granularity to perform the desired operation: applying changes to
>     > mainline that smallfeatures has but mainline does not.
> 
>     > I've asked this question repeatedly but never gotten an answer I
>     > understand.
> 
> Perhaps, for the simplified scenario you are describing, `replay' is
> what you want.  Replaying, rather than star-merging, smallfeatures
> into mainline might have been another way to get the result you
> wanted.
> 
> But suppose that I have merged from release into _both_ mainline and
> smallfeatures and now want to merge from smallfeatures into mainline.
> 
> Arch can recognize, sure, that some changes from smallfeatures have
> been applied to both.  What it can't tell is whether, when you merged
> from release to smallfeatures you, took those changes "as is" or made
> some further changes to those changes that only appear on
> smallfeatures.  So when merging back from smallfeatures to mainline,
> it would have to "subtract out" the changes from release and see if
> you made any "changes to changes" that should be copied to mainline.

Ok, I can understand where the difficulty arises (thank you).  

>From the way you describe it, it sounds like the problem could be
completely avoided by adopting a discipline of never making any manual
changes when committing a merge; any desired changes to the merged
changes should be committed as a separate changeset.  This does not
remove any expressive capability from arch, it just requires merges to
be broken into two steps.

Are either of these statements true?

1. Adhering to the discipline I have described allows the algorithm I
described (apparently called pure-merge) to handle all cases that
star-merge can handle.

2. Adhering to this discipline will give pure-merge the capability to
cover cases that star-merge cannot, such as the situation the original
poster described.

Especially if (2) is correct, this discipline seems to be one that is
well worth adopting.  It is not oppressive, it just requires an extra
commit before making changes to a merge.  The only problem I can imagine
is if you are forcing every revision to pass a test suite or fulfill
some other criteria that the merge alone may not fulfill.

Josh