[darcs-devel] rebase squash

[Ben Franksen]

Am 15.05.20 um 13:10 schrieb Ganesh Sittampalam:
> On 15/05/2020 09:27, Ben Franksen wrote:
>>> then yes, we can tell if they have conflicts simply by
>>> doing what unsuspend would do.
>>>
>>> But of course this brings us back to what I think was one of your
>>> motivations for rebase squash: that suspending+unsuspending patches
>>> produces conflicts we'd rather it didn't.
>>
>> Exactly!
>>
>> And just now I had an idea that could explain why this (still) happens.
> 
>> My theory is that this is caused by V2 Duplicates.
> 
> Sorry, should have mentioned this up front as I did already think about
> that: I also get failures with V3, though they don't necessarily look
> the same as the V2 ones. You can probably generate them yourself by
> running the test I attached in my last email, otherwise I'll analyse and
> write up what I found as soon as I have time.

So much for my nice theory. Will try your patch and see for myself.

>>> Overall I'm still not sure that 'rebase squash' is a better idea than
>>> something operating on the main repository. I think doing it on the main
>>> repository would short-circuit a lot of the complexity we're discussing.
>>
>> Well, my initial motivation for doing this on suspended patches was to
>> circumvent the problem that we get these "extra" conflicts on unsuspend.
>> A squash for regular patches doesn't help with that.
> 
> But neither does a rebase squash that is careful to avoid squashing what
> it thinks are unresolved conflicts.

So we need a way to decide which conflicts are resolved in the sequence
of selected patches.

>>> Maybe the answer is to actually tag each dependency inside a rebase with
>>> a trail of the renames they've been through. Seems quite ugly though.
>>
>> I may be wrong but I think this is equivalent to my solution (1) i.e.
>> restrict commutation of name fixups with each other and with Named
>> patches so we never loose information. A sequence of rename fixups that
>> are stuck on a suspended patch really is the same as this "trail of
>> renames". Another way to see this is to consider how you would have to
>> change commutation rules for suspended patches if we added the "trail of
>> renames".
> 
>> As I said before, this may be the most practical solution here.
> 
> I think the difference is maybe in how we manage dropping the
> information. If we define the invertible commute using the trail of
> renames, then the only thing we have to do at unsuspend is throw away
> the trail. If we just block the commutes, then we need a more
> sophisticated force-commute for unsuspend time, that also does some
> renaming at the same time as reporting on actual dropped deps.
> 
> So no fundamental difference in user experience, just a question of code
> design. I kind of like the idea of more things commuting, but dislike
> the idea of having to have a trail of anything.

If you add the rename trail, you still have to think about how that is
affected by (and affects) commutation of suspended things (Fixup,
RebaseChange). I am pretty sure that in the end this won't gain us
anything. With restricted commutation of name fixups we'll need a few
more rules for force-commute, but I think this is manageable.