[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Default version for star-merge

From: Tom Lord
Subject: Re: [Gnu-arch-users] Default version for star-merge
Date: Mon, 12 Jul 2004 17:22:34 -0700 (PDT)

    > From: address@hidden (James Blackwell)

    > You're referring to what I call a multi-level star: 

    >        A ->
    >             B -> G,
    >             C -> E, F, H
    >             D -> F, I

    >                         F
    >                        /
    >                       D
    >                      / \
    >                     /   I
    >                   *A*
    >               F   / \
    >                \ /   \
    >                 C     B
    >                / \     \
    >               H   E     G

    > What you're saying is 'What if C meant to star-merge his H subbranch,
    > but forgot to specify the H subbranch and star-merged the default A
    > parent branch'

    > Well, one of two things. The user says whoops and says "Look,
    > there's new stuff in A anyways, so I'll commit it anyways" or "I
    > didn't mean to star-merge this way (at least not yet), so I'll
    > undo this"

Or three: the merge is conflictless and the C maintainer follows it up
by running tests and then committing, prematurely bringing unwanted
changes from A to C.

    > Failing all of the above, how about "star-merge --parent" ? 

I like that general idea.

How about something like:

        % tla star-merge +upstream

and for that matter:

        % tla whats-missing +upstream
        % tla update +upstream
        % tla replay +upstream

The next question is how "+upstream" should be defined in the
long-run.   Physical ancestry may provide a good default but
isn't always the right definition.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]