[darcs-devel] Handle the rebase patch at the repo layer [was: open questions regarding FileUUID]

Ben Franksen ben.franksen at online.de
Wed Jun 13 22:13:20 UTC 2018


Am 10.06.2018 um 18:55 schrieb Ganesh Sittampalam:
> On 08/06/2018 22:36, Ben Franksen wrote:
>> Am 08.06.2018 um 16:34 schrieb Ganesh Sittampalam:
> 
>>> Sorry for the very belated reply. I don't think this belongs in
>>> D.P.RepoType, which is basically a hack for dealing with things like
>>> rebase that should really be handled at the repository level rather than
>>> by smuggling groups of patches within a container patch.
>>
>> Hm, you are probably right with that. BTW, I would be very glad if we
>> could join efforts to eliminate this particular wart, i.e. handle the
>> rebase patch at the repo level. I have the feeling this shouldn't be
>> that hard to do.
> 
> I'd also be happy to do this, though I remain worried about the safety
> of the repository code (and hence the danger in changing it substantially).
> 
> Are there any existing mailing list posts I should re-read about your
> ideas for doing this? Although I've been reading everything, I don't
> remember it all and I didn't spot anything directly relevant when
> looking back recently

I don't think I have written about this particular move in detail yet.

First of all, let us make it clear that this is not about
re-implementing the rebase patch itself as a sequence of regular patches
at the repo layer. This is momentarily out of scope, it would be a lot
of effort and the gain questionable. Rather, what this is about is
reverting the decision to mix the rebase patch with the normal patches.
It will become a (single) special patch like the pending patch or the
unrevert bundle. This would obviate the need for the D.P.Named.Wrapped
layer, the type level programming in D.P.RepoType and consequently the
'rt' type parameter for PatchInfoAnd and Repository. We could remove a
lot of the complication in D.R.Job and also lift restrictions for
operations that move patches out of a repo with a rebase in progress.

I understand your reservations wrt changing the Repository code. What
you gained by mixing the rebase patch with the normal patches is that
this more or less automatically updates the rebase patch whenever
patches are added or removed from the repo (except in the special case
of amend, where we pay special attention to preserve explicit
dependencies). If we store the rebase patch separately, we have to do
all of this "manually", similar to how we handle the pending patch. I
have been working a lot on the repo code in the last year and in the
process it has lost most of its scariness for me. (I also have a few
simplifying patches in petto that aren't in screened yet, mostly
concerned with Pending; I have also written an in-depth analysis of how
tentativelyMergePatches works, including pretty pictures in ASCII :). So
I feel confident I can get the integration of a separate rebase patch
right without introducing too many bugs. (The quite comprehensive test
suite you wrote for the rebase commands will also help a lot.)

The actual rebase commands are a somewhat different matter. This code is
quite involved and I'd say you are best suited to adapt it. We can try
to hammer out a rough first version of an interface to the Repository
layer (read, write, and what else may be needed) and I can try to
implement it (this is probably easy, all the difficult stuff is already
there inside Darcs.Patch.Rebase).

For integration into the rest of Darcs (via the Repository layer) it
would be nice if we had support from the type checker, but I can't see
how to get the kind of assurance we want, i.e. that we get a type error
if we forget an update to the rebase patch or add/remove patches in the
wrong order. I have been thinking about how to do this on and off but so
far failed to arrive at an elegant solution. If you have any ideas for
this, even very rough ones, don't hesitate to share them. If we could
solve this riddle we could apply the solution to the Pending patch, too,
to make this part of the code base more robust.

Cheers
Ben



More information about the darcs-devel mailing list