[darcs-devel] darcs 2.16 TODOs

Ben Franksen ben.franksen at online.de
Tue Jul 21 08:16:34 UTC 2020

>> There is one more point wrt rebase. I remember you sent two more patches
>> attached to one of our long discussions about the three rebase variants,
>> one with a test and one that changes the order of the force commutes on
>> unsuspend, which definitely improved the behavior with conflicted
>> suspended patches. I am not sure these were ever screened and I think
>> they should go into 2.16.
> Thanks for the reminder. I think it was patch2020 and indeed it appears
> never to have been screened.
> From what I remember that's ok to go in as-is but I would have to look
> through again to be completely sure.

It would be helpful if you could do that. I also think it was marked WIP
so the patch name should be amended before screening.

>> Sorry for that! I was already thinking about marking patches as "should
>> / should not go into 2.16". I think I will stop sending patches that
>> aren't intended for 2.16 until we are ready for release. Note that the
>> last 8 or so patches are all quite simple follow-ups on your review. I
>> can self-accept them if that helps.
> It's fine if you want to, though most of my time goes in reading the
> more complicated patches so it's unlikely to make much difference.
> In general if you do want to make progress and I appear to be
> hibernating again it is also fine to self-accept more complicated
> patches after waiting a while. But I hope we can get 2.16 over the line
> soon.


>> There is one patch on the tracker that I haven't screened yet because it
>> introduces a changes in behavior and I wanted to give you time to
>> consider that properly. This bundle also contains fixes to the output of
>> rebase commands when used interactively. That makes me think it should
>> perhaps go into 2.16. I do think the behavior changes are an
>> improvement, but if you disagree or want to postpone the decision I
>> think I could break out the refactors and the fixes.
> This is patch2055? Apologies, I thought your plan was just to run with
> it locally for a while before screening.

That was one half of the plan... ;-)

> If you're also waiting for
> comments from me I will try to take a look soon.

The other half was to ask what you think about the behavior change.
Which is, basically, this: in interactive mode, when you hit 'x' darcs
displays /only/ the summary and does not repeat the patch info.
Likewise, when you hit 'y' or 'p', it shows only the patch content and
does not repeat the patch info.

To achieve that, I had to make a few changes to the ShowPatch class and
redefine the meaning of some of its methods.

When it came to adapting the 'instance ShowPatch RebaseChange' I noticed
that for this patch type the implementation was already ommitting the
patch info (for methods summary and showNicely). But that means the
commands did not do the right thing when '-s' or -'v' is given on the
command line because then the patch info is not displayed either. Indeed
you can easily verify that this is the case with the current screened.
Another problem with the instance is that it does not display
information about the explicit dependencies, in contrast to the instance
for Named which does that. My patch solves both these problems and thus
brings the rebase patch display on par with the rest of darcs. I did
keep the special way in which RebaseChange displays conflicts in verbose
mode, though.

>>>>> - document "darcs-3" format appropriately so that people don't use it by
>>>>> mistake
>> Where/how do you think this should be documented? I think the only way
>> to produce a darcs-3 repo now is by using 'darcs init --darcs-3', so
>> perhaps this would be the right place?
>> Do you think we should also add a warning when this command is invoked?
> Yes, I think both would make sense.


> Do we intend to maintain backwards compatibility? Or should we warn
> people that their darcs-3 repos might in principle be broken by future
> changes? I'd be in favour of the latter to give us maximum freedom.

Same here. I don't want to promise any kind of compatibility either.
I'll come up with a warning and appropriate docs.


More information about the darcs-devel mailing list