[darcs-users] rebase feedback and amend-record flexibility

Florent Becker florent.becker at ens-lyon.org
Tue Apr 10 19:14:11 UTC 2012


Hi Michael,

>> As per previous mails in the thread, darcs semantics currently prevent
>> editing patch metadata without changing the identity of both implicit
>> and explicit dependencies.
>>
> 
> I understand how the identity of ask-deps dependencies must change (since
> they're recorded as references to patchinfo).  I don't see how other
> dependencies must change.  Can you provide an example?  Ignoring ask-deps
> dependencies, every scenario I've thought of can allow deep metadata
> changes without affecting any other patches.
> 
> 
>> Note that if you can't commute patches to
>> the front then there is a stack of dependencies that would need to have
>> their identity changed when editing the underlying patch.
>>
> 
> Sometimes that's true, but it doesn't seem to be true in the general (or
> common) case.  Can you provide an example so I can see what I'm missing?
> 
> Coalescing two adjacent patches seems to be a safe operation (assuming no
> patchinfo changes) because the coalesce has no net effect on the filesystem
> on which subsequent patches operate.  As far as subsequent patches are
> concerned, the coalesce was a noop.  I'm probably missing something
> obvious, so a counterexample would be great.
> 
For both points, there is at least one common reason: darcs' algorithms
rely on the fact that if two repositories R1 and R2 share a patch p,
then they also share any patch p depends on. If you don't ensure that
invariant, then pull for instance will start doing weird stuff. For
instance, if r1 and r2 have patches abc with c implicitely depending on
a and b, if in r1 we coalesce a and b into [ab], what happens when we
pull from r1 into r2? Should we offer [ab]? How would we merge it? What
about the case where r1 and r2 coalesced a with b1 and b2 which conflict?

Florent



More information about the darcs-users mailing list