bzr resolve

[Stephen J. Turnbull]

Aaron Bentley writes:

 > It we could see why it was poor, we wouldn't have written it that
 > way.

People are more complex than that.  At least I believe I am, and on
that basis I assume others are too. ;-)

 > The statements "nowhere is the no-argument form recommended" and
 > "[the no-argument form] it is mentioned exactly once in "bzr help
 > resolve,"" seem contradictory to me.  Can you explain what you
 > mean?

Mentioned != recommended.  If you mean that normally the no-argument
form should be used, you can write "Normally, the no-argument form
should be used, as it checks that conflict markers have been removed.
The form 'bzr resolve FILE' is used when you want to mark a file as
committable despite the presence of conflict markers."

 > > of the semantics of "bzr resolve" with no arguments, which still
 > > isn't clear to me.)
 > 
 > You said:
 > 
 > > 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.
 > 
 > And I said:
 > 
 > > That sounds like what it does.

I can have no idea why you introduced ambiguity into your reply.  I
can only assume my description was more or less inaccurate, no?

 > What else would you like to know?

We can stop here, else I'd start to feel qualified to rewrite the docs
myself.<wink/>

 > I don't understand.  --take-this resolves conflicts in favour of
 > THIS.  Are you saying the command does not make decisions because
 > the user specified the way that the conflict should be resolved?

Yes.  Of course "bzr resolve --take-this" "chooses" a replacement for
the current file in the workspace where several options are available,
and so at a low level makes decisions, but at the level that users
mean when they say "I wish bzr would resolve more conflicts than it
does," it is refusing to guess as the Zen recommends.  That's a good
thing, of course, but it is less convenient than a good oracle.

 > We need --all because the default behaviour is safe.  Kind of ironic
 > that it engenders distrust.

Huh?  Of course you don't *need* it.  Unless you have a project
written by some kind of crazy people, "bzr resolve" will get all but a
very few of the files that have been fully resolved, leaving a very
short list (normally empty!) that can easily be handled with the "bzr
resolve FILE" form.  If you have such a project, and you can't change
its practices, "bzr resolve `bzr conflicts`" DTRTs, no?

As for "irony", not really.  There is a widespread convention that
"dangerous" actions are enabled with "--force" or "-f".

 > > Nobody (but you) seems to like the fact that "bzr resolve" and "bzr
 > > resolve *" have semantics that differ in a way that almost
 > > guarantees that "bzr resolve *" is a bug.
 > 
 > OTOH, that behaviour was introduced in 2007, and it hasn't been an
 > issue 'till now, so perhaps most people are happy with it, and only
 > those who disagree are talking.

Point taken.  By the same token, it could be that few people use
wildcards with resolve, so it can't bother them, too.

 > In Bazaar, that will often cause recursive behaviour, because * will
 > select the subdirectory, and bzr usually recurses into specified
 > subdirectories.  (Much like ls -r)

But unlike no-option "ls *".  I think I myself would not build in
recursive behavior where there are other ways of obtaining it, but
many VCS operations are naturally recursive.  The majority of users
might expect recursion, I suppose.

Steve