[darcs-devel] Rebase implementation: patch vs. repo level

[Ben Franksen]

Hi Ganesh

a while ago we talked about the rebase implementation. You mentioned that 
rebase should have been implemented on the repo level (but was not for 
various practical reasons). I was thinking about this a few days ago when I 
noted that a rebased patch always looses its identity, i.e. gets amended, 
even if it's just suspend + immediate unsuspend.

Which makes rebase a bit less useful than it could be. I am now using 
obliterate -O / apply if I just want to temporarily remove changes without 
amending them. A repo-level implementation could be better in this regard, 
making rebase suspend/unsuspend the tool of choice for operations that 
_potentially_ rebase a number of patches.

A cool feature that could come out of this: when a rebase is in progress and 
I pull or record changes that might force a later unsuspend to amend 
patches, darcs could warn me that this is the case and ask if I want to 
unsuspend the affected patches first to avoid that.

Now to a related question:

Am I right that implementing rebase on the repo level would mean adding yet 
another phantom type to Repository, something like

data Repository (p :: * -> * -> *)
  wRecordedstate wUnrecordedstate wTentativestate wRebasestate

? Or do we need two new states in order to also represent the "fixup" needed 
to adapt the rebase patches to new records or pulls (or even just 
modifications of the working tree, not sure if that is needed). And the list 
of patches that makes up the rebase state, where would it start? At the 
wTentativestate or at wUnrecordedstate or even at wRecordedstate?

I have no concrete plans to (re-)implement rebase on the repo level; rather 
trying to understand the issues involved and get a better feel for what the 
witnesses on the Repository type really mean.

One thing I do not understand about the Repository witnesses: I may have a 
wrong understanding of what "tentative" means, but judging from the comment 

-- the recorded state of the repository (i.e. what darcs get would 
retrieve),
-- the unrecorded state (what's in the working directory now),
-- and the tentative state, which represents work in progress that will
-- eventually become the new recorded state unless something goes wrong.

shouldn't wUnrecordedstate and wTentativestate always be equal whenever we 
start executing a command and be again equal when we finish with it? And if 
yes, could we perhaps express this more directly in the types of the 
functions involved?

Cheers
Ben
-- 
"Make it so they have to reboot after every typo." ― Scott Adams