Patch 2324 WIP properly track context changes when we rename a patch

Title WIP properly track context changes when we rename a patch
Superseder Nosy List ganesh
Related Issues
Status in-discussion Assigned To

Created on 2023-07-01.20:43:37 by ganesh, last changed 2023-07-08.11:44:33 by bfrk.

File name Status Uploaded Type Edit Remove
patch-preview.txt ganesh, 2023-07-01.20:43:36 text/x-darcs-patch
wip-properly-track-context-changes-when-we-rename-a-patch.dpatch ganesh, 2023-07-01.20:43:37 application/x-darcs-patch
See mailing list archives for discussion on individual patches.
msg23479 (view) Author: ganesh Date: 2023-07-01.20:43:37
This is Ben's patch following up on the discussion in patch2257

1 patch for repository darcs-unstable@darcs.net:/opt/darcs/screened:

patch f5f8d93cc49e104e93dbc900b6ce066c6418f7a1
Author: Ben Franksen <ben.franksen@online.de>
Date:   Tue Jun 27 15:36:41 BST 2023
  * WIP properly track context changes when we rename a patch
msg23491 (view) Author: bfrk Date: 2023-07-04.19:01:10
In the discussion at patch2257 you wrote

> IMO the real issue is that the witnesses for `AddName` etc should really
> live in an orthogonal namespace to the witnesses for patch contents. The
> no-op commutes are actually a smell that they should happen for free.

It would be nice if we could have completely separate patch theories for 
Names (with explicit dependencies) on the one hand and a for Content (with 
implicit dependencies) on the other; and then combine them in a generic way 
e.g. by saying that the product of Name and Content commutes iff both 
components commute. But to make this actually useful we also need a way to 
represent name changes and pure content changes explicitly, like in Rebase, 
which means we actually need a mixture of product and sum similar to 
'These', when we combine Name and Content.

It seems that what you are saying is that the witnesses for those theories 
would "naturally" belong to different kinds, and that the witness kind for 
the sum/product would be a product of those kinds. This might be so, but, 
verbosity and technical difficulties aside, I don't think it is actually 
necessary. The trivial commutes which you claim have a "smell" are just 
another way to express the same idea without separate name spaces for 

My patch is meant to show how this could be done. The idea is that when we 
construct a Named patch from PatchInfo and content, we track the addition of 
the name by also constructing and returning a suitable RebaseName patch that 
removes that effect. For updatePatchHeader, this is a Rename. The patch is 
incomplete because when we record a new patch we should also create a 
DelName, when we unrecord an AddName, etc.
msg23500 (view) Author: bfrk Date: 2023-07-08.11:44:33
Extending this to all operations involving named patches is a huge 
deal. For instance, fullUnwind would have to return something like 
(Unwound p, Maybe2 RebaseName) and then we get error cases when 
calling fullUnwind on unnamed patches. I think I'll give up on this 
for the moment.
Date User Action Args
2023-07-01 20:43:37ganeshcreate
2023-07-04 19:01:13bfrksetmessages: + msg23491
2023-07-08 11:44:33bfrksetstatus: needs-screening -> in-discussion
messages: + msg23500