Quite a few people (at least me and Simon Marlow) like to resolve conflicts one
at a time. The natural workflow for this is to pull all non-conflicting patches
first, and then pull the conflicting ones one at a time, but I don't know of any
easy way of getting the non-conflicting ones first.

Just tacking on issue1263 as a related bug (it wants a 'conflicted'
matcher)

Might as well merge this with issue1263

I'm not actually convinced that what's needed for this bug is the same as for
issue1263; in particular --match is about existing properties of patches whereas
the option to pull would be more about potential conflicts. It also has to cover
conflicting patches and dependencies of conflicts, whereas a --match option
might well not do that.

Removing the duplicate for now but happy to discuss it further.

I've investigated a bit and I see two possible implementations (both of which
are quite easy to actually do; I already prototyped one of them).

One option is a new flag, --only-unconflicted (happy to discuss the name too).

This would cause darcs pull (and for free darcs apply since it goes through the
same code path anyway) to filter the list of selected patches before applying
them to the repo.

The second option is to tweak the behaviour of the existing
--dont-allow-conflicts flag (and perhaps the similar flag for darcs apply).
Right now it just errors out if the selected set of patches have any conflicts.
However an alternative would be to change it so it acts as a filter on the list
of patches presented to the user for selection (or that -a would select
automatically). This has the appeal of being conceptually simpler, and also
giving the user the opportunity to see what patches they are getting. However I
don't know what the impact of changing the existing behaviour of the flag would be.

This was resolved in Darcs 2.4 with the introduction of the new
--skip-conflicts flag