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

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

[Gnu-arch-users] Safer star-merge (was Re: darcs vs tla)


From: Catalin Marinas
Subject: [Gnu-arch-users] Safer star-merge (was Re: darcs vs tla)
Date: Mon, 22 Nov 2004 18:00:23 +0000
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Catalin Marinas <address@hidden> writes:
> The 'star-merge --three-way' (*not* the standard one) algoritm can be
> modified to cope with cherry-picking. The common ancestor of 2
> branches is the last revision before the first 'tla missing' reported
> revision between these branches (maybe it already does this). If a
> patch was cherry-picked from one branch into the other branch,
> 'star-merge -t' would report a conflict in the files modified by the
> cherry-picked patch.

Actually, this should be the default for star-merge (either the
standard or the --three-way one). It is much better (safer) to fix the
star-merge conflicts caused by an already cherry-picked patch rather
than not applying the patches before the cherry-picked one at all.

So, the new definitions reported by star-merge -H could be:

MAYBE_ANCESTOR_1 is defined as the highest patch level of FROM in
REFERENCE before the first missing patch between TREE and FROM. In
other words, it is the latest consecutive REFERENCE revision of FROM's
version already merged into TREE.

MAYBE_ANCESTOR_2 is defined as the highest patch level in REFERENCE
before the first missing patch between FROM and REFERENCE.  In other
words, it is the latest consecutive revision of REFERENCE already
merged into FROM.

Does this sound feasible?

Catalin





reply via email to

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