[darcs-users] On merging
Anthony Towns
aj at azure.humbug.org.au
Sat Nov 27 03:57:03 UTC 2004
Anthony Towns wrote:
> So applying X, inv(X), then Y isn't the same as just applying Y if X and
> Y conflict. Surely /that/ has to be a bug? Please? :)
I wonder if this would be more appropriate for a darcs-theory list, or
if I should be using my blog, or darcs-devel, or something, but anyway...
So, here's my theory: if merge always works, commutation can always work
too.
Say you have a patch Q that depends on a patch P; so that you "can't
commute" patch Q and P. We'll denote it like this: your original
repository is R, P applied to it is P(R), Q applied to that is Q(P(R)).
We want "P'(Q'(R))". Further we'll suppose merging works by taking your
original repository X(R), and the repository you're pulling from, Y(R),
and gives you a new patch M(Y,X) which is "the changes of Y, when merged
with X".
What we _can_ get is:
Q(P(R)) (duh)
or P^-1(P(R)) (inverting P just gives us R again)
But we know that we can merge any two patches that apply to the same
repository, and Q and P^-1 both apply to P(R). That gives us:
M(Q,P^-1) ( P^-1(P(R)) )
or
M(Q,P^-1) ( R )
But we can apply both M(Q,P^-1) and P to R, so we can merge _them_ too,
and get:
M(P, M(Q,P^-1)) ( M(Q, P^-1) ( R ) )
and if you set Q'=M(Q,P^-1) and P=M(P,Q'), we've just commuted P and Q!
I shudder to think what this would actually end up looking like in
darcs. Although I note that the final formula looks a lot like an
"unwind" formula.
My hypothesis: having commutes work like that would be horrible,
confusing and bad, therefore having merges work like that must be
horrible, confusing and bad too!
I wonder if you could make darcs still be useful if you forbade pulling
conflicting patches in the same way you can't commute dependant patches;
then you could only pull something that did an "addfile ./foo" if you'd
already mv'ed your ./foo out of the way, eg. The trick would come in
dealing with pulling something that did "addfile ./foo; ........;
rmfile/mv ./foo". Although maybe it'd be best just to disallow that too;
unless it was "bundled up" into a single patch that you'd deal with
atomically. Dealing with hunk-conflicts would obviously need thought
(and automation) too.
Hrm, maybe I'm thinking about this wrong -- maybe I could try writing a
"merge" user interface that invoked darcs repeatedly and munges around
in _darcs for seeing how these things work... Why, yes! I think that'll
work well...
(Except I hate writing user interfaces. Still, guess it's about time I
learned, now I'm a MacOS freak and all...)
Cheers,
a "muahahaha" j
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 155 bytes
Desc: OpenPGP digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20041127/f6977d7b/attachment.pgp
More information about the darcs-users
mailing list