[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