Please create "unobliterate", equivalent to "unrevert".  In fact, perhaps it could actually just be "unrevert", and unrevert could be made to undo the last revert *or* the last obliterate.

On Fri, Dec 30, 2005 at 04:00:22PM +0000, Zooko wrote:
> Please create "unobliterate", equivalent to "unrevert".

I'm hesitant to add more commands, but this wouldn't be too hard to
implement.  We could just keep a patch bundle of obliterated patches, and
then unobliterate would be equivalent (in terms of coding) to apply with
that patch bundle as an argument.

If someone wants to code this up, that would be great.  On the other hand,
it also might be worth having a discussion on darcs-users as to whether
"unobliterate" would be a good name, or if there's something else that is
even better that we could do.  Mostly just because as I said above, I
hesitate to add new commands.  Unobliterate would also negate the purpose
of the extreme nature of the "obliterate" name, which was meant to indicate
that it's irreversible...

> In fact, perhaps it could actually just be "unrevert", and unrevert could
> be made to undo the last revert *or* the last obliterate.

No, I think that would be confusing, since unrevert would then sometimes
act only on the working directory and sometimes on both the inventory and
working directory.
-- 
David Roundy
http://www.darcs.net

> > In fact, perhaps it could actually just be "unrevert", and unrevert could
> > be made to undo the last revert *or* the last obliterate.
> 
> No, I think that would be confusing, since unrevert would then sometimes
> act only on the working directory and sometimes on both the inventory and
> working directory.

I meant that if you obliterate followed by unrevert that you get the changes
re-applied to the working directory, but not the patch restored to the
inventory.

I nominate for this "wont-fix". 

If we support this feature, there will be no way to recover the disk space from
deleting patches without manually editing the internal files. 

I'm also with David on being cautioius on adding more commands. 

I've used Darcs since 1.0, and haven't needed unobliterate. 

And indeed, having a command like this makes the name "obliterate" inaccurate.

Okay, since it was my wish and no-one has echoed it, I hereby mark it as wont-fix.

A better alternative that introducing a new "unobliterate" command, would be to:

- modify obliterate so that it un-applies a patch, creates a patch bundle  
  and just *moves* said patch bundle to _darcs/trash/ ... by default.
                                                                                                                                                      
- modify obliterate to accept some sort of a "--forever" argument which
  does *completely remove* the patch (i.e. the way it currently functions)
  instead of moving it to the _darcs/trash/
                                                                                                                                                      
- ensure any patches in _darcs/trash/ can be easily `darcs apply`-ed
  (i.e. recovered). 

This keeps the interface simple, and makes the obliterate command a tiny bit
safer, by not letting users shoot themselves in the foot by default.

This sounds like it would be fairly easy to implement for a new darcs hacker. 
Shall we accept this?

If you do want to work on this, I would be interested in working with you to
turn it into a You Too Can Hack on Darcs article.

I expect that if we add unobliterate, people will start using obliterate /
unobliterate like "git stash" / "git stash apply". Which is not what
"obliterate" is for. Perhaps we can add a reversible obliterate as "darcs stash"?

> I expect that if we add unobliterate, people will start using obliterate /
> unobliterate like "git stash" / "git stash apply". Which is not what
> "obliterate" is for. Perhaps we can add a reversible obliterate as "darcs stash"?

So instead of
    darcs obiliterate           # actually stores a copy
    darcs obiliterate --force   # really deletes

We have

    darcs stash
    darcs obiliterate # keeps working as is.

I think I like this proposal. It keeps backwards compatibility with our
current functionality. Also, it provides a new function similar one in git, 
using a similar name, making it easier for people to switch from git.

Of course, the reason to add the feature is because it feels useful, not
because git has it. As long as their name for the function is reasonable, 
I see no reason to make up a new one.

    Mark

On Fri, Oct 24, 2008 at 14:43:02 -0000, Mark Stosberg wrote:
>     darcs stash
>     darcs obiliterate # keeps working as is.

At present, I use darcs send -O to do what (I think) stash does.

Note also that the purpose of original request is so that people
can do a darcs obliterate and then undo if they regret the move.
So we would need to see to it that obliterate itself offers a way
to auto-stash.

On Fri, 24 Oct 2008 15:47:34 +0100
Eric Kow <kowey@darcs.net> wrote:

> On Fri, Oct 24, 2008 at 14:43:02 -0000, Mark Stosberg wrote:
> >     darcs stash
> >     darcs obiliterate # keeps working as is.
> 
> At present, I use darcs send -O to do what (I think) stash does.

I use this too, but I felt like I thought of a clever trick when when it
occurred to me to use 'send' this way. The semantics of 'stash' are better. 

> Note also that the purpose of original request is so that people
> can do a darcs obliterate and then undo if they regret the move.
> So we would need to see to it that obliterate itself offers a way
> to auto-stash.

Either way, users have to understand that one version means "delete with
backup" and one means "delete permanently"

Like on a desktop when you have "move to trash" and "Shred". No one is trying
to make "Shred" recoverable, but that feels like what we're trying to do with
with obiliterate auto-stashing.

What we really want here is to add a new "Move to Trash" command, which is recoverable.
Or shall I say, "Move to Stash'.

( Hey, so maybe "Trash" is better metaphor than "Stash", because that's how people are 
used to using the desktop UI? It's at least more evocative for me than "stash", which is
just an abstract word to me. ) 

    Mark

> I like obliterate, I think it's great, I use it all the time. But it
> would be good if it were recoverable. Essentially, obliterate will *always*
> remove something that at one time had a real value to me. Why not make it
> safe?

The name is concern. obliterate sounds like "completely destroy".

I could be OK with one command, but it should be something like

darcs trash
darcs trash --obiliterate

Not this:

    darcs obiliterate --really-delete

That looks redundant. 

We could keep "darcs obiliterate" as a hidden alias to mean
darcs trash --obliterate"... I recall we've done that for other
commands.

That way, we have some backcompat, but the docs are cluttered with an
additional command.

    Mark

On Fri, Oct 24, 2008 at 03:03:55PM -0000, Mark Stosberg wrote:
> 
> Mark Stosberg <mark@summersault.com> added the comment:
> 
> Either way, users have to understand that one version means "delete with
> backup" and one means "delete permanently"

It's ridiculous to have two delete patch commands. The whole idea is
that the application should help prevent you from fucking up. Not: that the
user is expected to pro-actively save themselves from themselves by
enabling X command switch.

> Like on a desktop when you have "move to trash" and "Shred". No one is trying
> to make "Shred" recoverable, but that feels like what we're trying to do with
> with obiliterate auto-stashing.

Why is the concept of shredding i.e. permanently deleting, a priority in
a VCS? A VCS is essentially an elaborate *backup* tool isn't it? 

> What we really want here is to add a new "Move to Trash" command, which is recoverable.
> Or shall I say, "Move to Stash'.

I like obliterate, I think it's great, I use it all the time. But it
would be good if it were recoverable. Essentially, obliterate will *always*
remove something that at one time had a real value to me. Why not make it
safe?

On Fri, Oct 24, 2008 at 03:56:52PM -0000, Mark Stosberg wrote:
> 
> Mark Stosberg <mark@summersault.com> added the comment:
> 
> > I like obliterate, I think it's great, I use it all the time. But it
> > would be good if it were recoverable. Essentially, obliterate will *always*
> > remove something that at one time had a real value to me. Why not make it
> > safe?
> 
> The name is concern. obliterate sounds like "completely destroy".

I agree, the word 'obliterate' is completely unambiguous. And for 99% of
cases its meaning will be perfectly understood and the command will be used
as intended. It is (IMO) an *excellent* choice for a command name.

What I am suggesting is more of a silent modification to the command. If
people are looking for implementation solutions, perhaps it could be made
so that only the last obliterate was stored.

> I could be OK with one command, but it should be something like
> 
> darcs trash
> darcs trash --obiliterate

IME when you muck around with the interface you make people unhappy. 

I also do not think that 'trash' is a superior verb to 'obliterate'.

> Not this:
> 
>     darcs obiliterate --really-delete
>
> That looks redundant. 

Fair enough. I only suggested adding a --really-delete flag to make a
subset of the existing user base happy.

> We could keep "darcs obiliterate" as a hidden alias to mean
> darcs trash --obliterate"... I recall we've done that for other
> commands.
> 
> That way, we have some backcompat, but the docs are cluttered with an
> additional command.

Trash is an additional command - and for my money (still 2c) a less
immediately understandable one.

Cheers,
Alex

I like the pattern that darcs has with "darcs revert", which seems to  
me (as a naive user who doesn't know the internals) to be that revert  
destroys your work, but that vestiges of it happen to be left lying  
around as a matter of convenience/performance, and darcs unrevert can  
recover from those vestiges if you are lucky.

This is perfect for me -- the fact that "darcs unrevert" is  
unreliable prevents me from counting on it, but it is always nice on  
those rare occasions when I suddenly realize that I need it.

I guess "darcs obliterate" could work similarly.  "darcs  
unobliterate" would be a command that only works sometimes, and only  
because "darcs obliterate" is trying to be efficient and simple by  
not actually deleting data.

--Z

We now have two candidate mechanisms, one storing a set of bundles in some
_darcs/trash and one storing a single unobliterate bundle akin to the unrevert
patch with few guarantees of reliability (i.e. we'll have warnings like 'pulling
this patch will make it impossible to unobliterate! Proceed [yn]'

Do-er decides, perhaps.

See also issue557 (which wants an unpull/obliterate distinction)

I think Florent's darcs obliterate -O effectively resolves this (with
maybe some documentation)