bzr resolve

[Stephen J. Turnbull]

Aaron Bentley writes:

 > What is the rationale for specifying FILE when you don't want to
 > override the automatic behaviour?

That I haven't yet fixed the conflicts in other files, of course.

In general, I mistrust "automatic" behaviors; they very often bite me
where I can't see them coming.  Bazaar is supposed to be better
(there's lots of testimony to that effect) but what "bzr resolve" (in
any form) does is poorly documented -- *I* at least have little
confidence that it will DWIM, let alone DTRT in areas I haven't
thought carefully enough about.  So I would *never* use "bzr resolve
--all" (especially now that vila confirms that it behaves as
documented ;-) and it would take a lot of convincing to get me to use
"bzr resolve" (no options).  Especially now that it's clear that bzr
developers' intuitions differ from mine on this command. :-)

I really don't understand your aversion to safe, reliable behavior
here.  Merges are the most dangerous operation a VCS can perform.  IMO
bzr should do its best to help me confirm that the commit is as clean
as bzr can make it, rather than rely on my claim that I got it right.
If somebody wants the current behavior, just alias "resolve" to
"resolve --force".

It would be different if for historical reasons or something you were
forced to use "^-- $" or something like that for a conflict marker.
But the herringbone markers are extremely rare in the wild, and the
"=======" marker occurs very occasionally in restructured text and I
suppose other plain text markups.  However, even there (at least in
ReST) it's very easy to work around (just use 8 or more "=" where you
need 7).