Issue 2606 improve handling of dependency swaps

Title improve handling of dependency swaps
Priority feature Status wont-fix
Milestone Resolved in
Superseder Nosy List bf
Assigned To

Created on 2018-11-01.15:55:47 by bf, last changed 2019-01-25.12:54:31 by bf.

msg20433 (view) Author: bf Date: 2018-11-01.15:55:44
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.


    |  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

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.
msg20544 (view) Author: bf Date: 2018-11-20.16:25:50
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.
msg20647 (view) Author: bf Date: 2019-01-25.12:54:29
Dependency swaps are unsound so this is now obsolete.
Date User Action Args
2018-11-01 15:55:47bfcreate
2018-11-20 16:25:52bfsetmessages: + msg20544
2019-01-25 12:54:31bfsetstatus: unknown -> wont-fix
messages: + msg20647