gnu-arch-users
[Top][All Lists]
Advanced

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

Re: [Gnu-arch-users] Re: Potential flaw in patch-log pruning in proposal


From: Thomas Lord
Subject: Re: [Gnu-arch-users] Re: Potential flaw in patch-log pruning in proposal
Date: Thu, 28 Oct 2004 09:55:15 -0700 (PDT)

    > From: Matthieu Moy <address@hidden>

    > > So: how about we modify the process so that we maintain a file

    > >         ./src/tla/=merged

    > > Each time a (log-pruned) version is merged into tla, it's version name
    > > will be appended to that file.   No version name should appear twice
    > > in that file.

    > Wouldn't it be better to let (a future version of) tla maintain this
    > file, and integrate it in the arch protocol instead of some user
    > convention?

The GNU mainline integrator, according to the rules, only ever has to
perform two kinds of merges to deal with contributions.  Both are
simple star-merges followed by log pruning.  The log pruning varies
slightly in the two cases.

Yes, those merge operations can and eventually should be automated,
and they can update the =merged file accurately AND be
history-sensitive to the contents of that file.   

Jblack's conundrum about branches A, B, and C in the OP of this
thread: C's problems would be solved by using these new mythical merge
commands (which are perhaps little more than two new options to
star-merge).

-t




reply via email to

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