To: gnu-arch-users@gnu.org
References: <20041107234609.7bf0abfe@delta.hk.office.outblaze.com>
	<tnxlldcbqm1.fsf@arm.com>
	<D4D5B1A3-31DC-11D9-B0B3-000393CFE6B8@spy.net>
	<1099995711.2900.84.camel@stargate>
	<1100306258.7511.56.camel@localhost>
	<20041113122841.GA13424@fencepost>
	<20041116081231.GS10330@patrick.wattle.id.au>
	<tnxsm72dx8g.fsf@arm.com>
From: Catalin Marinas <catalin.marinas@arm.com>
Date: Mon, 22 Nov 2004 18:00:23 +0000
In-Reply-To: <tnxsm72dx8g.fsf@arm.com> (Catalin Marinas's message of "Mon,
	22 Nov 2004 09:55:11 +0000")
Message-ID: <tnxpt25pxvs.fsf_-_@arm.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [Gnu-arch-users] Safer star-merge (was Re: darcs vs tla)
Precedence: list
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 1536
Lines: 39
Catalin Marinas <catalin.marinas@arm.com> 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


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/