[darcs-devel] rebase squash

[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.

>> 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.

>> 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.

Cheers,

Ganesh