[darcs-devel] rebase squash

Ben Franksen ben.franksen at online.de
Mon May 11 18:38:59 UTC 2020


Am 11.05.20 um 07:22 schrieb Ganesh Sittampalam:
> On 11/05/2020 00:10, Ben Franksen wrote:
> 
>> I agree that WithDroppedDeps is not particularly complicated in itself.
>> But the existence of NameFixups does complicate in-place editing of
>> suspended patches.
> 
> Can you explain what the sticking point is? Intuitively I wouldn't have
> considered it any worse than PrimFixup. For example if I wanted to
> squash AddName into a patch that depends on that name, I'd just remove
> the dependency.

I'm confused. Did you mean DelName instead of AddName?

> I have a feeling that all the other cases where a NameFixup gets stuck
> in the rebase state actually indicate bugs, though I'm not 100% sure of
> that without thinking it through more carefully.

I have thought a bit how to properly handle NameFixups.

Ignoring prims we basically have a sequence

  name_fixups1 deps1 name_fixups2 deps2 ... name_fixupsN depsN

We want to squash the deps by taking their union. But first we have to
get rid of the NameFixups. For this we need a function that (force-)
commutes a NameFixup past a Named patch. This does not change the fixup
at all, but it changes the deps in the Named:

  AddName n          what to do here? can that happen?
  DelName n          remove n from deps (and warn about it?)
  Rename o n         rename (any) o to n in deps

The reason we must commute them past and cannot just eliminate them is
that further suspended patches might depend on affected names, too.

That sound correct to you?

>> Here is a typical scenario: I have made a simple but perhaps not
>> completely trivial patch, followed by a large and complicated refactor
>> with a detailed long comment that depends on the first one; and some
>> more patches following. For some reason or other I want to fold the
>> first patch into the second, but I don't want to loose the log for the
>> second patch. So I suspend it, obliterate the first, and then either
>> amend the second one manually (perhaps I have kept the file in my editor
>> and re-save it to get the same end state); or I re-pull it from a clone,
>> resolve conflicts, then unrecord and amend. In any case anything
>> explicitly depending on the first patch looses the dependency. If I were
>> notified about this immediately, and had a way to edit the affected
>> patches immediately to replace the dependency, I would probably do so.
>>
>> But of course it would be even better if this were done automatically.
>> That requires an explicit (rebase) squash command that automatically
>> pushes NameFixups that rename /all/ squashed patches to their (single)
>> replacement. I am not sure the existing commute and force-commute
>> functions for NameFixups would handle such a case correctly, i.e. the
>> case where one or more renames "clash" with each other or with existing
>> explicit deps.
> 
> I see, so we really need some kind of squash command to communicate the
> user intent that we are actually replacing two patches with one.
> 
> I wonder if it needs to be within the rebase state, though. We could
> also have a "darcs squash" command or perhaps "darcs amend-record
> --squash" that integrates patches in the main repository with each
> other. Not sure if it's any better or worse overall but it would
> eliminate the need to deal with fixups.

True. OTOH you have to deal with possibly conflicted patches instead.
I'd have to look up how amend handles it, I guess it just takes the
effect. And we still have to make sure that "clashing" rename fixups are
handled properly.

Cheers
Ben



More information about the darcs-devel mailing list