RFC: migrating to git

[Florian Weimer]

* Simon Marlow:

> Thanks for this.  I distilled your example into a shell script that
> uses git, and demonstrates that git gets the merge wrong:
>
>   http://hpaste.org/42953/git_mismerge
>
> Still, git could get this merge right, it just doesn't (I know there
> are more complex cases that would be very hard for git to get right).
> I suspect that in practice this rarely matters, because context-based
> merging usually does the right thing.

Git will have a very hard time getting this right because it is not
that history-aware.  It's also unlikely that this is implemented
because this mismatching of changes happens only rarely, unless you
have a coding style which heavily relies on copy-and-paste.  (It has
happened in real-world merges, though.  It is also easy to construct
similar examples involving file renames, I believe.)

I know only one criterion for merge correctness: developers working
serially on the code base would end up with the same result.  (This is
based on the concept of a serializability in transaction processing
systems.)  It is clear that no system can satisfy this.  For instance,
suppose you have a LaTeX document for one-page flyer.  Obviously,
there is a very hard requirement that you can have only one page of
text. Two parallel edits can satisfy this constraint, but their
automatic merge might not. (Zooko's example is different in that there
is an apparently correct solution, so it is not absolutely necessary
to bail out, but of course, the authors could likely squeeze their
content on a single page, too.)

Inevitably, you have to make trade-offs.  The Git approach seems to
suit more developers and codebases than the darcs approach.  Git
mismerges are much rarer than non-completing darcs merges.

On the other hand, speaking as a non-contributor, the requirement to
deal with multiple version control systems seems awkward.  But the
current sub-tree approach also feels a bit clunky (same as for
OpenJDK, by the way).