Re: [Gnu-arch-users] Re: --forward mostly harmless

[Harald Meland]

[Miles Bader]

>   If star-merge had a `--commit-if-pure' option, which would
>
>    (1) Check the pre-merge tree for changes, and if any are found turn
>        off the `commit flag'
>
>    (2) Make sure that _all_ patch-logs contained the being-merged changeset
>        (even those that are already present in the project tree) have a
>        "Pure-Merge:" header.  (if not, turn off the commit flag)

Wouldn't requiring such a header raise a chicken-and-egg problem?
Whose responsibility is it to add such headers to the revisions you're
trying to merge?

Is it part of your design that this variant of star-merge won't work
on any tree in which *any* changeset representing "hacking"
(i.e. changesets that are actual code improvements, without which the
point of having merging functionality becomes moot) is present, unless
these also have the Pure-Merge: header (presumably due to it being
added by hand (or, in your case, by the cvs-to-tla gateway)) ?

>    (3) For each new patch-log in the being-merged changeset (those that
>        aren't already in the project tree), make sure it points back to an
>        existing patch-log via the "New-patches:" header (possibly
>        transitively; you already know they're all `pure' from step [2]).
>        (if not, turn off the commit flag)
>
>    (4) If the commit flag is still on at this point, do sync-tree instead
>        of merging the changeset, and commit the result.

That is, mark the new revisions in the to-be-merged changeset as
merged (by having sync-tree add their patch-logs), but don't actually
include the non-patchlog changes in the to-be-merged changeset?

I don't see what purpose this would serve...

>    (5) If the commit flag is off, printing a message and merge as usual
>        without committing
>
> This seems much safer than --skip-if-present, and seems like it would work
> as intended for my usual scenario.
>
> -Miles

-- 
Harald