[darcs-users] A proposal: patch incoherence

David Roundy droundy at abridgegame.org
Sat Nov 20 15:06:22 UTC 2004

On Fri, Nov 19, 2004 at 08:34:02PM +0100, Juliusz Chroboczek wrote:
> Sorry for making once again a proposal that I don't have time to
> implement right now.  I'll get back to darcs hacking sometime in
> March, but right now it's simply not an option.
> I recently claimed[1] that patches are immutable, and I was right.  I
> hence concluded that rerecord/amend-record and unrecord are heresy,
> and, after thinking about it, I was wrong.
> I also suggested that darcs should implement a notion which I called
> ``patch subsumption''.  Marnix Klooster[2] later clarified that notion
> by calling it ``patch conflict''.  As the term ``conflict'' is already
> used for merges, I prefer to call it ``patch incoherence''.

Your patch incoherence idea does seem like it could be a useful concept,
but I have a few reservations.

First, while incoherence alleviates some of the dangers of the "dangerous
commands" (i.e. amend-record and unrecord, which must currently only be
applied to "nonpublic" patches), it doesn't really make them safe, but only
eliminates the restriction to "nonpublic" patches.  On the other hand, it
is precisely this restriction that most commonly causes trouble with these
commands, so it may be worthwhile.

Secondly, the patch incoherence moderates the "benefits" of these unsafe
commands, and in one sense makes them less "safe".  (Safe has so many
different meanings...)  If I'm on a private machine (noone else has access
to my repository), I'd like to be able to amend-record a given patch dozens
of times without leaving snail trails in the history so that everyone in
the world knows what a klutz I am.

The idea that an unrecord would create an empty patch incoherent with the
unrecorded patch is a bit repulsive.  It doesn't really guarantee any
safety, since I could just unpull the empty patch, or simply not push it
into another repo.  So my leaning would be that unrecord would not leave
any history behind.

In addition, I would think there should be an --unsafe option to
amend-record which prevents this accumulation of incoherence annotations.

> 3.3. Patch refusal

The trick of adding an incoherent empty patch when refusing a patch doesn't
strike me as a good idea.  The problem is that it keeps you from changing
your mind later.  If the contributor makes a bunch of improvements so now
the feature is acceptable, you can't pull them, since they depend on a
change that you are incoherent with.  If you've tagged your repository, you
can't unrecord that little empty patch, since it's in the tag.

One could try to define an inverse incoherence patch (although I would
think incoherence would be an attribute like a dependency, rather than an
actual primitive patch type), but then you get into some rather scary

> 4.4 Arch-style merges
> Darcs merges are the right thing in many cases.  However, they some-
> times are not desirable, either because you want to keep track of the
> history of the merge, or because they generate too many conflicts and
> hence are unbearably slow.  In that case, you find yourself wishing
> that Darcs could implement Arch-style merges.
> Arch has three algorithms for performing merges.  However, all three
> have the same structure, and only differ in the precise definition of
> point (i) below:
>  (i)   select the set of patches to merge;
>  (ii)  perform a sequence of (two- or three-way) merges on your
>        working tree;
>  (iii) record the resulting patch.
> All of that can be done in darcs (and I have done so repeatedly).
> However, since point (iii) generates a patch that subsumes the patches
> merged from, it requires patch incoherence in order to be safe.

I really think this is a bad workaround for the inefficiencies in the
merger code.  After doing this arch-style merge, you can no longer merge
with any patches that depend on any of the set of patches that you merged.
Once this merge has been performed, everyone has to switch to using the new
merged patch, which is not a good situation.

In summary, your incoherence idea does seem to me to be useful in making
amend-record truly "safe", but other than that seems of limited
usefulness.  And even in the case of amend-record, I'd want to be able to
avoid creating any incoherences.
David Roundy

More information about the darcs-users mailing list