Re: [tlug] Open-source repository question

[John Fremlin <john@example.com>]

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.