This is related to the scenario that triggered issue2605. To recup, we
have two repos R1=A1:>B, R2=A2:>B, where B depends on either A1 or A2.
For instance, A1 and A2 could be independently recorded patches that
make the same change.

We now record another patch C on top of A1:>B, that depends on B. We
want to pull C into R2=A2:>B /without/ pulling A1.

We can achieve this by first merging A2:>B:\/:A1:>B:>C to
A1':>C':/\:A2', then trying to commute out the unwanted A1' i.e. A1':>C'
<--> C'':>A1''. If that succeeds we can drop A1''. Otherwise we can't
pull C alone because it also depends /directly/ on A1.

                 R1
       -------------------->

    |  o--A1-->--B-->--C-->o
    |  |                   |
    |  A2                  |
    |  |                   |
  R2|  v                  A2''
    |  |                   |
    |  B                   |
    |  |                   |
    |  v                   v
    v  o-----A1'---->--C'->o

In practical terms, this amounts to first pulling A1 along with C and
then obliterating it. You can do that now, with separate invocations of
darcs.

It would be nice if we could do this with a single pull: when we are
asked about A1 and we say 'no', then we should be still be offered C,
even though it depends on B which depends on A1, /if/ A1':>C' commutes.
This means patch selection needs to consider /both/ sequences, not only
the one from which we select patches. It also means we need to perform
merges on the fly /during/ selection. Integrating this is with the
existing mechanisms for patch selection is not trivial.

Here is one idea how merge-by-value can be supported in the UI.

When we select remote patches during a pull, a special key for 'minimize
dependency' could be offered. This would be treated similarly to 'w',
with the difference that if such a patch turns out to be needed to
fulfill a dependency, then it should be amended by throwing out all
unneeded content i.e. retain only the prims that patches we really want
to pull depend on.

Or perhaps this should be an option for pull, and after patch selection
we are asked again about the automatically selected patches and whether
we want to minimize them; similar to how rebase pull asks us about
patches to suspend in a second pass. The UI should allow, probably even
strongly suggest, to edit the patch name in order to avoid confusion
when pulling again from the same repo.

Dependency swaps are unsound so this is now obsolete.