Re: [Gnu-arch-users] NEW: --forward options (alternative to --skip-present)

[Tom Lord]

    > From: Robert Collins <address@hidden>

    > On Sun, 2003-09-21 at 15:33, Tom Lord wrote:
    > >     > Simple case:
    > >     > How will it handle double-application of a patch into a tree where
    > >     > function names used in the patch have changed?

    > > Don't merge from that branch.   You're playing awefully fast-and-loose
    > > with the meaning of the presence of a patch log entry.

    > Into that branch. I must have been unclear.

    > In mainline:

    > - foo(bar, baz);
    > + foo(bar, baz + 1);

    > in the branch
    >   bettername(bar, baz + 1);

    > /* already merged from the origin of the baz->baz+1 change */


If this is a recurring, serious obstacle: make an intermediate branch
that tracks one end -- performing the function rename.   Automate the
function rename with a sed script or something fancier.   Merge from
that intermediate branch.

In other words, reify the identifier rename as changesets.


    > How is that 'fast and loose' ? Perhaps you could define precisely -what-
    > a patchlog presence in the tree means, because I *thought* I grokked it,
    > but apparently, I don't.

What it "precisely" means is what it causes various arch commands to
do.  What we're talking about is inevitably just "rules of thumb".

You're trying to map a very abstract notion of functionality merges
(e.g., even across things like identifier renaming) onto the much
lower-level notion of changeset application.   Then, in cases where
your changeset doesn't really express what you want it to, you're
papering that over with --skip-present (at least in this
identifier-rename example).    

An intermediate branch would lead to a closer mappign of functionality
merges to changeset merges.

-t