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

[Miles Bader]

Miles Bader <address@hidden> writes:
> The "different merge paths" I mention above are not necessarily through arch
> (indeed that's the usual case where problems occur) -- to arch it looks like
> two original changes where made that happen to be identical.
>
> Also, suppressing changesets by detecting existing downstream meta-data is
> not always correct, because _truly_ pure merges are often simply not
> possible.

Considering a bit though (and no doubt merrily repeating the famous
pure-merge thread...), while I think an insistence on pure-merging could
never be any kind of default, it might be useful as an optional
optimization; for instance:

  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)

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

   (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
-- 
80% of success is just showing up.  --Woody Allen