[darcs-users] unpull vs obliterate

[Stephen J. Turnbull]

Alex Lance writes:
 > On Sat, Aug 09, 2008 at 12:38:49AM +0900, Stephen J. Turnbull wrote:
 > > Alex Lance writes:
 > > 
 > >  > If the unpull command is to continue its life in darcs then
 > >  > yes that behaviour of making it safe, so that you don't
 > >  > accidentally "unpull" i.e.  delete, your single copy of a
 > >  > local patch, appears to be desirable functionality.
 > > 
 > > No, this is *undesirable* functionality.  The point of obliterate is
 > > indeed to delete your single copy of a local patch (for unlikely but
 > > possible example, under a court order) without otherwise harming your
 > > repository.
 > 
 > I think from an end-user/UI perspective it makes more sense that an
 > "unpull" command, does not easily allow you to delete patches that don't
 > exist elsewhere

I'll concede that it is unintuitive that unpull works on a patch that
was never (and can't be) pulled from elsewhere.  It does make sense to
separate the unpull command from the obliterate command in the UI,
although the API implementing it probably could usefully share most of
the code.

 > But regardless, as I said before I think a more favourable
 > path would be to completely remove "unpull".

If there is a "safe" version of unpull/obliterate (ie, it checks to
find the patch in the parent repo), then it should be called "unpull".

 > What I am trying to suggest is a simplification of the UI and concepts:
 > 
 > - Nuke the "unpull" alias 
 > - Keep "obliterate"
 > - Introduce "unobliterate".

"unobliterate" is an oxymoron.

 > > But then somebody will request the addition of a true (ie, unsafe)
 > > obliterate command.  Anyway, it is, after all, somewhat safer than
 > > "rm _darcs/patches/...".
 > 
 > I am not suggesting any major modification to the obliterate command.
 > For all intents and purposes it would function identically.

I've already mentioned an important intent and purpose to the
contrary.  Ie, the case of a court order or similar where somebody
with an acknowledged right (IP, privacy) requires that the patch be
deleted forever with no backups.

IOW, for reasons that have nothing to do with patch theory an
industrial-strength VCS should have a true obliterate command.  For UI
reasons it should have a name sufficiently scary and long that people
will refuse to use it without a court order. ;-)

 > I don't think I quite understand you. But I'm going to plow ahead
 > anyway :) My understanding is that the whole point of darcs is that given a
 > specific context the patches may be applied in any order. Ergo, patches
 > that are stashed/trashed/obliterated should theoretically be able to be
 > "unobliterated" and re-applied to the branch at any stage without
 > introducing any confusing UI. 

You're implicitly assuming that in any given project, the stashed
patches are few enough and salient enough to remember, and that there
are no dependencies among them other than those that Darcs can
identify automatically.

 > In fact, I suspect the introduction of an unobliterate command
 > creates a simpler and safer UI, and the symmetry of the
 > obliterate/unobliterate commands combined with the complete removal
 > of the unpull command would IMO *enhance* understandability,
 > without sacrificing anything.

I disagree on all counts.