Conflicts in removed files

Stephen J. Turnbull stephen at xemacs.org
Sat Dec 12 05:41:22 GMT 2009


Algis Kabaila writes:

 > brief how we (you and I) can make up a simple (articially made)
 > example to demonstrate the problem of apparently spurious
 > "conflicts" at merge.

As pointed out by David and IIRC Stefan, the conflicts are *not*
spurious.  The issue is more subtle.  Stefan sees the conflict, notes
that he wants to solve it in a particular way.  (It may even be the
case that he knows in advance how he's going to resolve it. (*))  What
he wants is for bzr (1) to remember his resolution for each file, and
(2) to automatically apply every time after that first time.  If (*)
is true, he might even like to (3) have bzr algorithmically recognize
the situation and apply the "generic" resolution the first time, too.

Note that (*) is not always true.  It may be that in the local branch,
the functionality of the file in question has been replaced entirely
with completely different algorithms, the bandaids applied in the
remote branch of no interest whatsoever, and you always want to
resolve by upholding the deletion of the file.  On the other hand, it
may be that the file was (in your mind) a *failed* experiment, while
to the hacker on the other branch it was a *so far unsuccessful*
project.  If she in fact succeeds, you may want to resolve the
conflict by restoring the file.  Note that in the latter case, your
judgment about restoring the file is likely to change only after she's
made several commits, each of which will raise the conflict.

 > As I have described in my previous email, I am very interested in
 > this, as I
 > 
 > 1. would like to avoid the problem you have.

As David explained, you probably will not face the problem, as I
understand your workflow.

Stefan's situation requires two long-lived branches.  In one branch
the file has been deleted, while in the other branch the same file is
under active development.  This is generally only going to happen in a
project with a publicly maintained "stable" branch, and usually will
be a recurrent issue only with multiple developers -- a single
developer is usually in a position to say "if the bug in the stable
branch bothers you that much, please use the beta branch."

 > 2. I would like to see how it can be solved once and for all.

It can't be "solved" because the right answer depends on human values
and judgment (or if you prefer evocative technical terms, an
"oracle").

The situation can be improved somewhat by implementing a "replay
recorded resolution" feature.  git has it under the name 'rerere',
which might be a useful starting place for a specification, as the
feature has been refined by over two years of heavy use by now.

I'm not sure whether it's a great idea to invoke it automatically, so
I guess you'd have to give the user a way to say "as far as I know,
I'll never want to resolve this a different way, so please do it
... I'll take responsibility for cleaning up any messes created by
blind application of the recorded resolution."



More information about the bazaar mailing list