[Top][All Lists]

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

[Gnu-arch-users] Questions on conflict resolution

From: Julian T. J. Midgley
Subject: [Gnu-arch-users] Questions on conflict resolution
Date: Tue, 6 Apr 2004 10:16:19 +0100 (BST)

I tend to use 'tla star-merge -t' instead of 'tla update' for bringing my
working copy up to date, since the 3 way diff produces conflict sections
that are more trivially resolved than .rej files, viz:

 <<<<<<< TREE
 some change
 conflicting change

Sometimes, however, I forget, and instinctively do a 'tla update'
(hangover from old CVS days).  Resolving the conflicts turns out to be
somewhat less trivial than I would have expected.  After an update that
results in a conflict in file "foo", there will be:

foo       : the file as it was in the repository, including any hunks
            that were successfully applied from the local changes
foo.orig  : the file as it was at this patch level in the repository
foo.rej   : a patch, from ANCESTOR to MINE containing the failed hunks

There is no copy of ANCESTOR to look at, however, to work out where those
failed junks were supposed to be in foo.  A lot of the time this doesn't
matter, because there's enough context to make it obvious; sometimes,
however, you do need it.  In these cases, the following algorithm seems to
work nicely for getting the rejected hunks into a form in which you can
work out what to do with them:

# fetch a copy of ANCESTOR to foo.ANCESTOR
cp foo.ANCESTOR foo.MINE
patch foo.MINE < foo.rej
diff3 -e -M foo foo.ANCESTOR foo.MINE

Two questions arise:

1. Is this really the most sensible way to go about resolving the
conflicts? Miles Bader's post about using diff mode in
emacs to assist appears to be useful, but seems not to work for me with
tla's .rejs because it can't find ANCESTOR to work from (it is possible I
am omitting some crucial step (an emacs mode for tla perhaps?) here).

2.  If it is, is there a straightforward way to determine what ANCESTOR
was /after/ the 'tla update' has been issued, assuming that I've also lost
the output of the 'tla update' itself and given that my working tree could
have been several patches behind the repository before the update was


Julian T. J. Midgley             
Cambridge, England.
PGP: BCC7863F FP: 52D9 1750 5721 7E58 C9E1  A7D5 3027 2F2E BCC7 863F

reply via email to

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