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

[Miles Bader]

On Mon, Sep 13, 2004 at 08:22:31PM -0400, James Blackwell wrote:
> > Ok, but I don't see (1) what this has to do with the issue of
> > eliminating duplicates (such duplicates almost always occur when
> > merging a changeset that was previously applied through a different
> > merge path, not from local duplicate changes), and (2) how it's
> > possible to automatically detect such a thing at merge time anyway.
> >
> > Maybe I just don't see your point yet.
> 
> Well, if we only did pure-merges, we could easily detect duplicates by
> examining whether or not the patchlog existed. But since we allow impure
> merges as well, we can't really tell whether or not a patch really has
> been applied.

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.

For instance, I maintain my personal version of emacs called `emacs-miles';
it is a merge of two emacs branches, emacs-lexbind and emacs-tiling, which
both track the emacs trunk.  So whenever I merge updates, I get identical
changes through both paths.  However, if a trunk change generates conflicts
with one of the two branches, and I need to modify the changeset accordingly,
the resulting adjustment is dependent on the branch it was made in
(emacs-lexbind touches code dealing with lisp language stuff, emacs-tiling
touches display code).  Because of this, I really need to apply patches from
both sources to emacs-miles, and remove duplicates at a low-level --
suppressing a `duplicate' changeset from being applied via one path because
it was previously applied via the other sometimes just won't work.

-Miles
-- 
If you can't beat them, arrange to have them beaten.  [George Carlin]