Documentation

This instance takes care of handling the interaction between conflict resolution and explicit dependencies. A conflict involves a set of two or more patches and the general rule is that the conflict is considered resolved if there is another (later) patch that (transitively) depends on each of the (mutually) conflicting patches.

This principle extends to explicit dependencies between Named patches. In particular, recording a tag has the effect of resolving any as yet unresolved conflicts in a repo.

In general a Named patch contains multiple changes ( a "changeset"). Consider the named patches

  Named A [] a
  Named B [] (b1;b2)
  Named C [] c
  Named D [A,B] _

where, at the RepoPatch level, a conflicts with b1, and c with b2. D depends explicitly on both A and B, so it fully covers the conflict between a and b1 and thus we would be justified to consider that particular conflict as resolved. Unfortunately we cannot detect this at the Named patch level because RepoPatchV1 and V2 have no notion of patch identities. Thus, at the Named level the two underlying conflicts appear as a single large conflict between the three named patches A, B, and C, and this means that patch D does not count as a (partial) resolution (even though it arguably should).

When we decide that a set of conflicting Named patches is resolved, we move the RepoPatches contained in them to the context of the resolution. For all other named patches, we must commute as much of their contents as possible past the ones marked as resolved, using commutation at the RepoPatch level (i.e. ignoring explicit dependencies).