[darcs-users] Patches are immutable
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,
> 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
> '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.
More information about the darcs-users