[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