Issue 174 obliterate silently stops when it reaches a tag

Title obliterate silently stops when it reaches a tag
Priority bug Status resolved
Milestone Resolved in
Superseder Nosy List darcs-devel, dmitry.kurochkin, kowey, markstos, thorkilnaur, tommy, zooko
Assigned To droundy

Created on 2006-05-18.09:02:07 by zooko, last changed 2009-08-27.13:58:12 by admin.

msg657 (view) Author: zooko Date: 2006-05-18.09:02:04
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.


msg658 (view) Author: zooko Date: 2006-05-18.09:05:11
> 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!


msg665 (view) Author: tommy Date: 2006-05-18.17:56:11
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

(Same thing with Unrecord.)
msg667 (view) Author: zooko Date: 2006-05-18.18:44:43
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.


msg2580 (view) Author: markstos Date: 2008-01-19.05:35:51
I have confirmed this still exists with Darcs2, and just 'sent' a failing test
to bugs/ that demonstrates the issue.
msg2617 (view) Author: tommy Date: 2008-01-20.00:54:02
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

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.
msg2618 (view) Author: tommy Date: 2008-01-20.00:58:24
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.
msg2654 (view) Author: droundy Date: 2008-01-22.15:10:15
I'm right now pushing a fix to obliterate (and unrecord) for this bug.
Date User Action Args
2006-05-18 09:02:07zookocreate
2006-05-18 09:05:13zookosetstatus: unread -> unknown
nosy: droundy, tommy, zooko
messages: + msg658
2006-05-18 17:56:14tommysetnosy: droundy, tommy, zooko
messages: + msg665
2006-05-18 18:44:44zookosetnosy: droundy, tommy, zooko
messages: + msg667
2006-07-03 20:01:02droundysetnosy: droundy, tommy, zooko
2008-01-19 05:35:52markstossetnosy: + markstos, kowey, beschmi
messages: + msg2580
2008-01-20 00:54:03tommysetnosy: droundy, tommy, beschmi, kowey, markstos, zooko
messages: + msg2617
2008-01-20 00:58:25tommysetnosy: droundy, tommy, beschmi, kowey, markstos, zooko
messages: + msg2618
2008-01-22 15:10:16droundysetstatus: unknown -> resolved-in-unstable
nosy: droundy, tommy, beschmi, kowey, markstos, zooko
messages: + msg2654
2008-01-22 15:11:42droundysetnosy: droundy, tommy, beschmi, kowey, markstos, zooko
assignedto: droundy
2008-05-02 09:11:11koweysetstatus: resolved-in-unstable -> resolved
nosy: + dagit
2009-08-06 17:34:01adminsetnosy: + jast, Serware, dmitry.kurochkin, darcs-devel, mornfall, simon, thorkilnaur, - droundy
2009-08-06 20:49:52adminsetnosy: - beschmi
2009-08-10 21:45:20adminsetnosy: - darcs-devel, jast, Serware, mornfall
2009-08-10 23:54:08adminsetnosy: - dagit
2009-08-25 17:48:43adminsetnosy: + darcs-devel, - simon
2009-08-27 13:58:12adminsetnosy: tommy, kowey, markstos, darcs-devel, zooko, thorkilnaur, dmitry.kurochkin