Re: [tlug] Open-source repository question

[John Fremlin <john@example.com>]

Stephen J. Turnbull wrote:
> git doesn't have a theory of patches at all ....

Git doesn't explicitly go on about a theory of patches in the same way
that darcs does, nor does it desperately grab at legitimacy by employing
mathematical notation from an unsound basis.

As you correctly noted in another email, darcs' theory of patches
doesn't take into account the actual semantics of a patch. (Of course
this would be very difficult.) Therefore, it cannot correctly determine
whether a patch conflicts with another, and relies on simple heuristics
based on the text of the patch, so that in fact its theory is not
correct in theory.

For example, from the Darcs theory of patches in
http://darcs.net/manual/node9.html


	The commutation of patches $P_1$ and $P_2$ is represented by

	\begin{displaymath}P_2 P_1 \longleftrightarrow {P_1}' {P_2}'.
\end{displaymath}

	Here $P_1'$ is intended to describe the same change as $P_1$, with the
only difference being that $P_1'$ is applied after $P_2'$ rather than
before $P_2$.

	The above definition is obviously rather vague, the reason being that
what is the ``same change'' has not been defined, and we simply assume
(and hope) that the code's view of what is the ``same change'' will
match those of its human users. The ` $\longleftrightarrow $' operator
should be read as something like the $==$ operator in C, indicating that
the right hand side performs identical changes to the left hand side,
but the two patches are in reversed order.

I think this clearly demonstrates that the darcs' theory of patches
isn't actually a formalised, and a formalisation of it that would allow
any patches at all to commute would be rather difficult, which may be
all very well for physicists and is absolutely fine if if actually works
well in practice, but it doesn't.


I would say that git has an implicit theory of patches. The idea is that
any significant change should have its own branch (very lightweight in
git), and when you want to merge a feature branch the work is automated
as far as sensible, but human intervention is required to determine
conflicts in terms of the semantics, etc. Rebasing the branch onto the
current mainline is also quite convenient (is that true in darcs?).

This theory is correct in theory, which is a massive step up from darcs,
and works in practice on projects with patch volume flows on the scale
of the Linux kernel, which is a massive step up from darcs.