bzr resolve

[Vincent Ladeuil]

>>>>> Stephen J Turnbull <stephen at xemacs.org> writes:

    > Vincent Ladeuil writes:
    >> There are valid cases where what looks like conflict markers generated
    >> by bzr are in fact a valid part of the file.

    > Of course, but they are rare.  The only time I've ever encountered
    > literal markers in the wild (outside of actually conflicted files) is
    > in documentation for VCS workflows, and even there typical style
    > indents them or wraps them in some sort of inline markup so that they
    > aren't recognized by the VCS.

    >> by design, 'resolve' is not meant to check whether a file contains
    >> conflict markers or not.

    > Hm.  I think you're missing a bet here.

    > Think about the semantics of checking.  If "bzr resolve FILE" checks
    > for conflict markers, and finds them, it marks FILE as conflicted, and
    > you can't commit.  Fail-safe.  Of course, you need a "bzr resolve
    > --nocheck FILE" option, but that's easy enough to implement and rarely
    > enough typed to be little bother.

Fair enough, s/--force/--nocheck/ for consistency but that's a valuable
proposition.

    > OTOH, currently, "bzr resolve" fails dangerously on typos and
    > wildcards in the command line.

Yeah, there are a few bugs left around where bzr can better handle
already resolved conflicts more gracefully. That's the main reason I
haven't reworked the command yet (search for "bazaar cannot
auto-detect..." in ``bzr help conflict-types``).

Until they are fixed, well, it's better to avoid:

- ``bzr resolve --all``: this is really nuking the conflict list
  without any check leaving detritus around,

- ``bzr resolve`` without any file or glob arguments as this doesn't
  generally do what you expect (as in: it works for "text conflicts"
  *only* (with the caveat discussed in this thread)).

    >> are conflicted and are the recommended commands to query bzr about
    >> the existing conflicts.

    > Speaking for myself, at least, I don't want to query bzr about
    > existing conflicts.  Again, think about the workflow:

    >     hack hack hack, bzr resolve, oh no what did I plan to work on
    >     next, bzr conflicts, hack hack hack, ...

    > Since you're already working interactively (unless you've got an
    > AI conflict resolver that you haven't contributed to bzr, hm?),

Hehe, no, I just do 'bzr st' in a shell buffer and edit each file
(letting emacs call ``bzr resolve FILE`` when I save the file after the
last conflict there has been resolved).

    > who need the "I'm confused" and "bzr conflicts" steps?  Why not
    > just have "bzr resolve" tell you what's left to do?

Well, my two main reasons are:

- resolve/resolveD is already confusing,
- there are still several holes in how the command behave.

Changing the intent and behavior at this point smells like we'll confuse
users even more.

There has been discussions about an interactive mode for conflicts and I
think qbzr implemented something. For bzr itself, the discussions
concluded that auto-resolving more conflict types was the first step and
then we could re-think how to better handle the overall workflow.

    > Maybe you have an alternative workflow where explicitly calling
    > bzr conflicts "only when needed" makes sense, or where having bzr
    > resolve check for the remaining conflicts would be annoying or an
    > actual impediment to getting work done,

No, as explained above, that's not the case.

    > but I don't see it offhand.  Except if there are many files (say
    > hundreds) changed by the merge (it's an obvious optimization to
    > ignore files that haven't been touched by the merge),

``bzr resolve`` indeed only cares about the known conflicted files.

    > when it would take a while to grep all those files.

I hope this clarifies my point of view,

     Vincent

P.S.: Many points above are already tracked in
https://bugs.launchpad.net/bzr/+bugs?field.tag=conflicts