Issue 2661 change the "after the latest clean tag" limitation for obliterate and unrecord

Title change the "after the latest clean tag" limitation for obliterate and unrecord
Priority feature Status unknown
Milestone Resolved in
Superseder Nosy List bfrk
Assigned To

Created on 2020-10-20.15:51:44 by bfrk, last changed 2020-10-21.19:17:53 by bfrk.

msg22492 (view) Author: bfrk Date: 2020-10-20.15:51:40
Some operations like obliterate and unrecord limit selection of patches to 
those after (and including) the latest clean tag. This is problematic for 
several reasons. On is that the concept of a "clean tag" depends on patch 
order. There is no way for users to observe whether a tag is clean or not in 
the current patch order. That makes it hard to predict which patches will be 
considered. Yet another problem is that regardless of whether a tag is clean 
or not, users may want to consider patches that a tag depends on as "frozen" 
-- which in fact they are, unless you unrecord or obliterate the tag first.

I propose that we change the condition to one that does not depend on patch 
order. More precisely, obliterate and unrecord (and perhaps others) should by 
default limit selection to patches that are not depended on by /any/ tag.

If the latest tag is clean (which it usually is) then this is exactly the 
same as before.
msg22497 (view) Author: bfrk Date: 2020-10-21.19:17:49
A slight correction wrt the actual behavior.

If the user specifies a matching option that counts as a "fist matcher"
i.e. one of the --from-xxx or --index=N-M variants (or the singular
match options but they are not supported for these commands), then the
restriction to patches after the last clean tag is not in effect. Same
if --not-in-remote is in effect; in which case the --from-xxx or
--index=N-M are ignored, but plural versions of "nonrange" match flags
(--patches or --matches) do take effect; because these are (also)
"nonrange matchers" and these are handled by the patch selection code.

See Darcs.UI.Commands.Util.preselectPatches for details, as well as

Any work on this ticket should include a cleanup of this mess.
Date User Action Args
2020-10-20 15:51:44bfrkcreate
2020-10-20 15:52:06bfrksetpriority: feature
2020-10-21 19:17:53bfrksetmessages: + msg22497