[darcs-devel] conflicting RebaseName fixups

Ganesh Sittampalam ganesh at earth.li
Sat Jun 6 13:59:12 UTC 2020


On 06/06/2020 14:33, Ben Franksen wrote:
> I have been wondering what rebase is supposed to do in the following case:
> 
> Start with two patches A;B where B explicitly depends on A, then
> 
> * Suspend B
> * amend A to A'
> * repull A from a clone
> * unsuspend B
> 
> Currently the behavior is that the amend renames the explicit dependency
> to refer to A'. We end up with the unsuspended B depending on A' as if A
> never existed and not even get a warning.
> 
> I think this is wrong. This is clearly a conflict! A and A' are both
> competing for the privilege of being B's dependency, and it should be
> the user's decision what to do here (depend on A or A' or both or none).

I think the more fundamental problem here is that both A and A' are
competing to exist. It only really makes sense to keep both of them here
if A' has fundamentally changed from A and at that point it's indeed
true that something that depends on it is probably depending on the
wrong thing.

I think we would need a substantially different model of what amend
"means" to a rebase to be able to do anything different.

> The situation is, I think, quite similar to a conflict between (addfile
> ./A) and (move ./A' ./A).

It's a good analogy because you will see the same "biased" behaviour
from rebase.

If we have patches X;Y where X creates A, Y changes A, then:

 * Suspend Y
 * Move A to A' and record
 * Create a fresh copy of A and record
 * Unsuspend Y

We end up with Y changing A' without any suggestion that the new copy of
A might be an alternative.

> The problem is that we have no way to express that RebaseName fixups are
> in conflict with each other.

I think it's more than that: we can't even engineer a conflict with the
current behaviour of RebaseNames, let alone handle that conflict.

Ganesh


More information about the darcs-devel mailing list