[darcs-users] Patches are immutable

David Roundy droundy at abridgegame.org
Sun Nov 7 13:07:19 UTC 2004

On Tue, Nov 02, 2004 at 08:18:17PM +0100, Marnix Klooster wrote:
> Not having used rerecord myself yet, and just to get this off my chest,
> but...
> Why should rerecord (and unrecord and unpull) not be used for a patch that
> has already been pulled?  If I understand correctly, this is to prevent
> conflicts and confusion.
> Here is a proposal, which should work at least for 'rerecord'.  Suppose a
> patch can not only indicate the patches it 'depends on', but also those it
> 'conflicts with'.  Then we can have 'rerecord' create a patch B that
> conflicts with the original patch A.  When patch B is pulled by some other
> repo which has A, that repo first has to remove A (and any dependent
> patches).
> 'unrecord' could simply be 'rerecord', but with patch B being an empty no-op
> patch.  'unpull' is similar.

One could do something like this, but this would greatly complicate pull,
as it would now be possible to lose precious data by performing a pull, if
that pull brings you a rerecorded version.

The real solution to "mutable patches" is to allow patch consolidation,
which is really a user-interface issue.  As such, it's also a pervasive
change, which is why it hasn't yet been done.

An interesting trick would be to allow true hierarchical named patches.
(I.e. a patch which actually contains other patches.)  This could have
certain efficiency advantages, and elegance advantages, but introduces the
question of how we deal with pulling a patch that "contains" a patch we
already have.  Probably this would just introduce unneeded complexity, and
a clever user-interface is the way to go.
David Roundy

More information about the darcs-users mailing list