Darcs.Patch.Depends

Documentation

getTagsRight :: PatchSet p -> [PatchInfo]

areUnrelatedRepos :: RepoPatch p => PatchSet p -> PatchSet p -> Bool

mergeThem :: RepoPatch p => PatchSet p -> PatchSet p -> Sealed (FL (PatchInfoAnd p))

findCommonWithThem :: RepoPatch p => PatchSet p -> PatchSet p -> PatchSet p :>> FL (PatchInfoAnd p)

countUsThem :: RepoPatch p => PatchSet p -> PatchSet p -> (Int, Int)

removeFromPatchSet :: RepoPatch p => FL (PatchInfoAnd p) -> PatchSet p -> Maybe (PatchSet p)

optimizePatchset :: PatchSet p -> PatchSet p

deepOptimizePatchset :: PatchSet p -> PatchSet p

slightlyOptimizePatchset :: PatchSet p -> PatchSet p

getPatchesBeyondTag :: RepoPatch p => PatchInfo -> PatchSet p -> FlippedSeal (RL (PatchInfoAnd p))

getPatchesInTag :: RepoPatch p => PatchInfo -> PatchSet p -> SealedPatchSet p

getPatchesInTag t ps returns a SealedPatchSet of all patches in ps which are contained in t.

splitOnTag :: RepoPatch p => PatchInfo -> PatchSet p -> PatchSet p :>> RL (PatchInfoAnd p)

newsetUnion :: RepoPatch p => [SealedPatchSet p] -> SealedPatchSet p

newsetIntersection :: RepoPatch p => [SealedPatchSet p] -> SealedPatchSet p

commuteToEnd :: forall p. RepoPatch p => RL (PatchInfoAnd p) -> PatchSet p -> PatchSet p :>> RL (PatchInfoAnd p)

findUncommon :: RepoPatch p => PatchSet p -> PatchSet p -> FL (PatchInfoAnd p) :\/: FL (PatchInfoAnd p)

merge2FL :: RepoPatch p => FL (PatchInfoAnd p) -> FL (PatchInfoAnd p) -> Sealed (FL (PatchInfoAnd p))

Merge two FLs (say L and R), starting in a common context. The result is a FL starting in the original end context of L, going to a new context that is the result of applying all patches from R on top of patches from L.

While this function is similar to mergeFL, there are three important differences to keep in mind:

• mergeFL does not correctly deal with duplicate patches whereas this one does (Question from Eric Kow: in what sense? Why not fix the mergeFL instance?)
• mergeFL returns both paths of the merge diamond, but this version only returns one, so you'd better choose the order carefully, eg. (merge2FL l r)
• The conventional order we use in this function is reversed from mergeFL (so mergeFL r l vs. merge2FL l r. This does not matter so much for the former since you get both paths. (Question from Eric Kow: should we flip merge2FL for more uniformity in the code?)