darcs

Issue 1844 support matchers for ask-deps

Title support matchers for ask-deps
Priority wishlist Status needs-implementation
Milestone Resolved in
Superseder Nosy List dmitry.kurochkin, ganesh, kowey
Assigned To
Topics Matchers

Created on 2010-05-12.14:31:23 by kowey, last changed 2017-10-16.23:19:41 by bf.

Messages
msg11055 (view) Author: kowey Date: 2010-05-12.14:31:22
Dunno if this is really a good idea (it may need to be Grumpy Old
Manned), but I found myself wishing I could do darcs record --ask-deps
--match foo once because the patch I wanted to depend on was really far
back.

This may not be worth the clutter...
msg11070 (view) Author: ganesh Date: 2010-05-13.23:16:21
In general I think anything that asks about patches should support 
matchers etc, so +1 for this proposal from that point of view.

The only problem I see is that normally it's the primary command 
("record", "pull" etc) that triggers patch asking, whereas here it's an 
option that triggers it. So if another option for record came along that 
also asked about patches, then it'd be ambiguous what --match referred 
to. Tricky...
msg19759 (view) Author: bf Date: 2017-10-16.23:19:40
One solution could be to allow to further restrict the candidates during
interactive selection: we add a command key (e.g. 'r' for "restrict
selection") that gives us a one-line prompt where we can enter a match
expression; then the whole undecided part of the selection gets filtered
and we re-enter the manual selection.

Such a feature would be generally useful, I think.

The next question is whether we want to allow to "un-restrict", too. Or
perhaps we want to make it possible to edit the match expression?
Perhaps even one that was given on the command line. Now that I think of
it, I am getting the as yet rather vague idea of merging /all/ matching
options into a generalized match expression. We could then define the
meaning of this language precisely, and the behavior of all matching
options (including combinations) would be defined by translating them to
a generalized match expression. I think this would allow us to close all
the various tickets regarding matching options with one big stroke.
History
Date User Action Args
2010-05-12 14:31:23koweycreate
2010-05-13 23:16:22ganeshsetnosy: + ganesh
messages: + msg11070
2017-10-16 23:19:41bfsetmessages: + msg19759