[darcs-devel] PrimWithName wrapper and UUIDs

[Ganesh Sittampalam]

On 25/02/2020 01:26, Ben Franksen wrote:

> OTOH, I think we already do that (propagate renames caused by amend or
> unsuspend into the rebase patch) to preserve explicit dependencies. The
> difference is that this now affects prims, too, whereas before we just
> had to adapt the explicit dependecies of Named patches. So I think the
> awkwardness would be limited to adding a few extra cases to some of the
> pushRenameFixupThroughPrim functions.

Yeah, I'm just not convinced it's worth it compared to saving an extra UUID.

Also how would anonymous add patches, such as in pending, unrevert or
rebase fixups, or just inside the code, work?

> I think the tipping point here is Darcs.Repository.Diff.treeDiff. This
> must be generalized to a method for some PrimDiff class under
> Darcs.Patch.Prim. The question is what to do with the types of the two
> input parameters, both Trees at the moment. Should they both become
> 'ApplyState prim'? In this case we would need another method that
> generalises readPlainTree and now returns an 'ApplyState prim' instead.

I guess we'd need a class, e.g. RepoState, which Tree and the new thing
would be an instance of, and then RepoState (ApplyState prim)
constraints all over the place, or it might become part of PrimPatch.

It may also be worth looking at http://bugs.darcs.net/patch1919, where I
experimented with replacing Apply with PrimApply. I have a feeling that
will reduce the messiness of propagating the new class around (but just
a feeling - it might not help at all).

Ganesh