I'm trying to obliterate a patch, and darcs exits with "No patches selected!". 

This is because there is a tag which depends on that patch.

The bug is that it doesn't offer me to obliterate the tag.  Secondarily, the
error message doesn't convey enough information to the user.

Regards,

Zooko

> I'm trying to obliterate a patch, and darcs exits with "No patches selected=
> !".=20
> 
> This is because there is a tag which depends on that patch.

Hm.  Actually, having obliterated all the tags in this repository, it *still*
says that.  So I don't know why it won't obliterate the patch.  Perhaps it is
because the patch is an UNDO patch?

In any case, this is a demonstration of the fact that the error message doesn't
convey enough information to the user!

Regards,

Zooko

Just putting in a note about a very related issue. Don't know if
it is relevant to the original bug report or if there is also a
bug with UNDO patches.

For efficiency darcs by default only offers to obliterate
patches up to the latest break point (tag). To obliterate older
patches one must 'darcs obliterate --from-something suitable
...'

Obliterate should in some way announce _that_ and where it
stopped.

(Same thing with Unrecord.)

Actually it turns out that obliterate *is* stopping because there exists a tag:

DARC yumyum:~/playground/darcs/darcs-stable$ darcs oblit -p'urp twice'
No patches selected!

And the reason there is a tag even when I thought there wasn't is that my
attempt to obliterate all tags runs into an internal error:

DARC yumyum:~/playground/darcs/darcs-stable$ yes | darcs oblit --tags="."

Fri Feb  4 08:38:05 AST 2005  David Roundy <droundy@abridgegame.org>
  tagged 1.0.2
Shall I obliterate this patch? (1/?) [ynWvpxqadjkc], or ? for help: 
darcs: bug in get_extra commuting patch:
Mon Apr 18 23:28:49 ADT 2005  Ian Lynagh <igloo@earth.li>
  * Remove tab

Opening a separate bug report for that.

Regards,

Zooko

I have confirmed this still exists with Darcs2, and just 'sent' a failing test
to bugs/ that demonstrates the issue.

I just got a hunch that the patch selection code is doing too
much work, or is not lazy enough. It is the slowness of
(interactive) patch selection with complicated dependencies that
can make obliterate painfully slow if you answers no to the
"wrong" patch.

What happens is that the no patch is commuted past _all_
preceding (or following) patches in the entire selection set, to
mark dependent (or depending) patches as no patches. This can
take a lot of time. Stepping through the patches with j/k
afterwards is quick, and one can see which other patches got a
no.

But for obliterating it is often not of interest to proceed
further down the inventory than to the last patch you want to
obliterate. So the implicit exclusion of selected patches could
be deferred until you interactively step to them (or scroll to
them in a GUI). Then it wouldn't matter how big the selection
set is, but only how far you step through it.

A different example of this is record with --ask-deps. The selection code (I
think) starts to commute away the explicitly depended upon patches, befor even
asking for a q(uit) or d(one), so if you have --ask-deps in the defaults file,
you sometimes have to ctrl-c the record and redo it with --no-ask-deps.

I'm right now pushing a fix to obliterate (and unrecord) for this bug.