interactive merge (was Re: [ANN][PLUGIN] extending diff with graphical tools)

[Martin Pool]

On 01/05/2006, at 6:28 AM, John Arbash Meinel wrote:

> Though I know I would prefer a more streamlined workflow overall.  
> Right
> now I do a merge, see the list of conflicts, and then edit the first
> one, and resolve it. Then the second... Then I type 'bzr conflicts'
> again because the list has scrolled out of site, and keep repeating  
> it.
>
> It would be nice if I could spawn an editor for each conflicted file,
> and when that file is saved, the file is marked as resolved.
> But I can see that as yet another plugin, rather than a core thing (at
> least in the beginning)

I tend to run

   vim `bzr conflicts`

which will bring up the first, and then I can type :wn to go to the  
next.  This works very well if most of the conflicts are simple  
enough that I can resolve most of them in alphabetical order.

More generally there are two different approaches to resolving  
conflicts or other situations:  either the user is in control (bzr,  
svn, cvs) or the computer is in control (unison, monotone,  
clearcase).  In the other model the computer asks you for each  
conflicting file what you want to do.

There are a few reasons why I originally wanted bzr to use the first  
of these:

  - for complex merges you might need to look at several files to  
work out what to do and you can't necessarily answer the questions in  
the order the computer wants to ask them
  - tools in the second model tend to insist on you resolving the  
whole thing right away and are intolerant of needing to reboot or log  
out (or of the merge hitting an error), or of wanting to leave a tree  
half-resolved for a long time
  - you can do resolution commands from more than one window at a  
time and use shell commands (bzr revert include) rather than doing it  
all through one program
  - dealing with large numbers of questions in a plain text user  
interface can be a bit tedious
  - it's more familiar for people coming from cvs/svn

But as you say sometimes it seems like we're just making the user  
walk around a lot.  Also, complex tree-shape merge operations can be  
simpler to present interactively, e.g.

   file foo.c
     yours:  modified (r132 by jane, "fix bug")
     other:  deleted (2006-3-11 by thom, "get rid of buggy code")
   what now? take yours/delete/show diff/help/...

(and many other cases such as a deleted directory with modified  
files, etc)_

Perhaps we can get the best of both worlds, particularly building on  
Aaron's code that records a structured description of conflicts.   
Since this can be saved to disk we can interrupt and resume the  
resolution process at any point, and we can start out non-interactive  
and go to interactive mode or vice versa.  So

   bzr interactive-resolve
   bzr interactive-resolve foo.c

This needs a better name - it's a bit of a shame we already used  
'resolve', but consistency with svn probably gets priority.

See also
   http://www.perforce.com/perforce/doc.992/manuals/cmdref/resolve.html

-- 
Martin