[darcs-users] darcs patch: Refactor Darcs homepage. (and one more).

[Stephen J. Turnbull]

Daniel Carrera writes:

 > I think I have an example.

An isomorphic example of David's was in the Darcs User Guide for a
long time.

 > It is of the form "a (potential) conflict that Darcs detects and
 > git doesn't". In summary, it's about whether two identical patches
 > should be a conflict or not.

I agree with you (and David before you) that in some ideal sense this
should be a conflict.

However, there are four problems with that point of view: (0) the
manual says Darcs 2 disagrees:

    If you are using a darcs-2 repository (Section ), darcs does not
    consider two patches making the same change to be a conflict, much in
    the same fashion as other version control systems.
    http://darcs.net/manual/node6.html#SECTION00625000000000000000

(1) most users disagree (which is why it was changed), (2) all the
more or less realistic examples I know in the programming domain where
we're right -- including yours -- depend on programming practices that
are so bad that every decent language[1] ends up inventing syntax to
avoid that error because it doesn't just fool VCSes, it fools
programmers too, and (3) the same argument applies to *all* non-exact
patches (ie, non-fast-forward merges, which is a concept that you
can't even express in Darcs in general repositories), with varying
degrees of plausibility.  That's because the right classification of
conflict here depends on the semantics of the underlying language,
which AFAIK patch theory doesn't care squat about (yet).

For example

$ cat >a.py <<EOT
def advance(x):
    return x + 2
EOT
$ cat >b.py <<EOT
# print the first integer after zero
import a
print advance(0)
EOT
$ vcs-du-jour init
$ vcs-du-jour add a.py b.py
$ vcs-du-jour commit -m "Numerological research."

At this point, Joe Overthere clones.  Now ...

$ echo "Uh-oh."
$ sed -i -e 's/2/1/' a.py
$ vcs-du-jour commit -m "Fix bug."

While over on Joe's workstation we see

$ echo "!@#$% library programmers!"
$ sed -i -e 's/print.*$/\1 - 1/' b.py
$ vcs-du-jour pull

Man, you just can't win for losing.

 > In this instance git happily merges and darcs sees a conflict. Darcs 
 > behaviour is correct.

That's simply not true in more generality than "in the case I just
invented for the purpose of proving this point", though.  In some
similar cases a happy merger is just what you want.  The verdict of
the users was overwhelmingly in favor of happy-go-lucky merging of
identical changes.

 > There is no way for the program to know if two 
 > identical changes are a conflict or not.

True.  But as I say, that claim generalizes to "there is no way for
[any existing] program to know if any merge is correct or not."

There is a way out of this problem.  And that's to focus on how Darcs
makes sane programming easier by checking what can be checked and
doing what can be done in typical cases, rather than focusing on a
spurious notion of correctness in edge cases.

Footnotes: 
[1]  Where the standard for "decent" is so low that C passes.

Ie, to fix David's example, instead of "#define ARRAY_MAX 25" you use
"enum { ..., ARRAY_MAX };".  To fix yours, the num_files file would
be generated automatically by make.