Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] Open-source repository question



Stephen J. Turnbull wrote:
John Fremlin writes:

> Correct, the point was that by splitting the example into patches in a > different way causes the original problem you described to appear in > both versions, so that in some sense they are equal.

Sure, in the sense that since 1 != 0 and 2 != 0, 1 == 2.

Sorry for not spelling it out.

Given two patches A and B that are identical on some content, and do not conflict on other content, the original conflict oracle O would claim that they conflict. The conflict oracle O' notes that the changes on the conflicted part are identical and claims that they do not conflict.

You might say that O' is "less correct" than O, because the set of patch pairs that it says do conflict is a strict subset of those that O says conflict, and the difference includes patches that in fact semantically conflict.

However, I say that notion is somewhat illusory. Given A and B, we can find patches C A' and C B', where C is a shared patch and A' and B' do not conflict. O would claim that C A' does not conflict with C B', though in fact they are semantically and textually identical to C A and C B. Therefore, by rephrasing the patches, without changing any of their textual or semantic effects, the O gives the same wrong answer as O'. This is the sense in which I wished to argue that they were identical. O actually has all the problems of O'.

Thus one might claim that O is less correct that O', because it more explicitly depends on the way the patches are subdivided.

[...]
So you're back to Curt's contention that you have to check every merge
as if it were a patch submitted by the black hats.  Which may work in
his shop, but it sure as hell doesn't work in any of XEmacs, Emacs,
Gentoo, Debian, Ubuntu, bzr (!), Darcs (!), MacPorts, or X.org, all of
which regularly release total brain farts so they're not checking
anything, let alone merges.

I don't see the advantages of checking the semantics of patches particularly assiduously.

Verify whether or not the software works and use git bisect if you can't figure out why it doesn't.

 > Yes. However, I think both of the patch conflict systems satisfy
 > all the reasonably necessary axioms for the conflict oracle (are
 > these articulated anywhere?).

I don't think anything text-based can if it doesn't satisfy "two
patches that touch the same text conflict unless they are identical
across the whole extent of the patch."

Why?

Please give an example where it breaks down.

It seems to me that you're obviously wrong by the patch decomposition argument above.

[...]
> For example, with reasonable axioms, it would be trivial to show that > given a valid conflict oracle that considers upper and lowercase to be > different, you could make a new one that does not consider upper and > lowercase to be different.

But that inference would be wrong for almost everything except Lisp
and BASIC.  So I don't know what you mean by "could make a new one"

From one Oracle satisfying the reasonable axioms, we can derive a new Oracle that also satisfies the axioms but doesn't care about case. Of course the semantics are very different if the file is not line based or semantically case sensitive, but we started this discussion recognising that the Oracle couldn't pretend to understand the semantics of patches.



Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links