bzr resolve

Stephen J. Turnbull stephen at xemacs.org
Thu Jul 26 06:37:09 UTC 2012


Ben Finney writes:
 > Bosco Rama <bzr at boscorama.com> writes:
 > 
 > > It's not the conflicts I was worried about.  It's the ability to stop a
 > > conflicted file from having the 'committed' version looking like this:
 > 
 > The way to stop that is not to use ‘resolve’ in that case. By using that
 > command, you're telling Bazaar that you know the conflict is resolved,
 > regardless of Bazaar's opinion.

Then resolve's documentation is buggy.  (In any case, it needs a
complete rewrite.[1])  Its description of the command says:

    Once you have fixed a problem, use "bzr resolve" to automatically
    mark text conflicts as fixed, "bzr resolve FILE" to mark a
    specific conflict as resolved, or "bzr resolve --all" to mark all
    conflicts as resolved.

That "automatically" strongly suggests some intelligence on the part
of resolve.

Sane behavior for "bzr resolve" with no arguments would be to

(1) check the tree for files containing conflict markers,
(2) update the list of conflicted files, and
(3) print the list.


Footnotes: 
[1]  (a) All uses of the verb "resolve" should be changed to "mark as
resolved."  (b) Where "resolve" has additional semantics, as the
--take-other and --take-this options apparently imply, these should be
spelled out explicitly.  Eg, "--take-this    Preserve the pre-merge
version in the working tree (discarding the merged version), and mark
the conflict as resolved."  (c) List the values that may be used for
ARG in the --action option.  (d) The Description should describe the
default output so that the descriptions of -v and -q are meaningful.




More information about the bazaar mailing list