Issue 2561 option --not-in-remote should be more consistent and for more commands

Title option --not-in-remote should be more consistent and for more commands
Priority feature Status unknown
Milestone Resolved in
Superseder Nosy List bf
Assigned To

Created on 2018-02-07.23:10:58 by bf, last changed 2018-02-07.23:10:58 by bf.

msg19849 (view) Author: bf Date: 2018-02-07.23:10:56
(1) --not-in-remote suppresses some of the match options. I don't think this
    is what users expect (I was surprised that e.g. darcs obliterate
    --not-in-remote --last=2 offered me all 17 patches that are not in the
    default remote). I think it respects so called 'nonrangeMatches' i.e.
    -h, --matches, etc, and only suppresses 'rangeMatches' (e.g. --last,
    from-xxx) but that's just from looking at the code; it looks as if the
    nonrange matching options are handled by Darcs.UI.SelectChanges, whereas
    the other are done inside the commands themselves.

(2) --not-in-remote <remote-repo> does not work, you need to say
    --not-in-remote=<remote-repo> ('=' instead of space). I guess this is so
    because the argument is optional but it is a bit surprising and should
    be documented somewhere.

(3) obliterate, unpull, and unrecord are the only commands that support
    --not-in-remote. IMO commands like amend and rebase suspend should, too.
    This wold require factoring the code that handles the option into
Date User Action Args
2018-02-07 23:10:58bfcreate