When using darcs pull --match xx --patch yy, darcs behaves like
darcs pull --match xx.

On the other hand, darcs pull --patch yy --match xx behaves like 
darcs pull --patch yy.

I would expect both commands to have the same result, that is 'and' the two
matches, or at least give a warning.

On Thu, Oct 23, 2008 at 6:17 AM, Florent Becker <bugs@darcs.net> wrote:
>
> New submission from Florent Becker <florent.becker@ens-lyon.org>:
>
> When using darcs pull --match xx --patch yy, darcs behaves like
> darcs pull --match xx.
>
> On the other hand, darcs pull --patch yy --match xx behaves like
> darcs pull --patch yy.
>
> I would expect both commands to have the same result, that is 'and' the two
> matches, or at least give a warning.

Additionally I could see the user meaning 'or'.  This is a case where
what we probably want is to have a little query language.  Like how
the find command has switches like -o.

Hmm...This requires more thought that I want to put towards it at the moment.

Thanks for the bug report!

Jason

I'll bet --match xx --match yy suffers the same way.

I think it's reasonable to change the behaviour so that --match xx --match yy is
equivalent to --match "X && Y"
(which generalises to the --match --patch case)

This sounds easy to fix.  I'd recommend starting by writing tests for --match xx
--match yy, --patch xx --match yy and --match xx --match yy, as well as three
matches.

Please shout if you disagree with the proposed UI

Could we say ?
1/ multiple "match" or multiple "patch" could be more efficiently 
handle within one REGEXP (with logical operator). The and/or have to 
be explicit in the REGEXP. => to fix the issue, just display a 
warning to avoid multiple "match" or "patch"
2/ at the end, we only have to handle mixed match/patch 
3/ the previous point have to be done for all commands with mixed 
match/patch

My take on this:

  --patch XXX is sugar for --match 'name XXX'
  --hash XXX is sugar for --match 'hash XXX'

These are both documented and quite obvious. This reduces the problem to
multiple --match options. I think it makes lots of sense to add:

  --match XXX --match YYY is sugar for --match 'XXX && YYY'

as proposed by kowey.

We should combine these transformations into a separate de-sugaring
phase prior to the actual patch matching code. This would allow us to
simplify the MatchFlag type as a first step toward (badly needed)
restructuring of the patch matching code.

I will have a look to implement code in the following way "combine these 
transformations into a separate de-sugaring phase prior to the actual 
patch matching code."



Le 17/06/2015 21:40, Ben Franksen a écrit :
> Ben Franksen <benjamin.franksen@helmholtz-berlin.de> added the comment:
>
> My take on this:
>
>    --patch XXX is sugar for --match 'name XXX'
>    --hash XXX is sugar for --match 'hash XXX'
>
> These are both documented and quite obvious. This reduces the problem to
> multiple --match options. I think it makes lots of sense to add:
>
>    --match XXX --match YYY is sugar for --match 'XXX && YYY'
>
> as proposed by kowey.
>
> We should combine these transformations into a separate de-sugaring
> phase prior to the actual patch matching code. This would allow us to
> simplify the MatchFlag type as a first step toward (badly needed)
> restructuring of the patch matching code.
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/issue1158>
> __________________________________

I am no longer certain this is a good idea (regarding --match X --match
Y as sugar for match 'X && Y'). The reason is that this covers only one
special case of combining matching options. There are many others, some
of which naturally combine and some of which really make no sense when
combined. Let me distinguish 4 groups of matching options: --from-x,
--to-x, --x (singular), and --xs (plural). I think we should allow at
most one option from each group. This more or less reflects what Darcs
is (and has been) doing all the time. The problem is that Darcs does not
complain but arbitrarily chooses one of the options, ignoring the other
one. Try for instance 'darcs log --tags=. --patches=1829' in the darcs
repo: no matter how you re-order the options, the --tags option gets
ignored. Properly fixing this needs some (re-)design work. Writing up a
consistent proposal has been on my TODO list for some time.

Anyone interested in this should take a hard look at
Darcs.UI.Options.Matching where all matching options are defined and
where the (currently) allowed combinations are listed.

I'm interesting to go further.

"we should allow at most one option from each group" could be to 
restrictive. I propose to go in more details to identify valid 
combinations of options.
The beginning is :
1/ all options must appear only once in the command line
2/ Darcs check valid combinations of options
3/ Darcs raises an error when encounters not valid combination

4 groups of matching options: --from-x, --to-x, --x (singular), and 
--xs (plural)

1/ hash (singular) exists but not hashes (plural). Is it OK ?
2/ tag and tags come to the same options OneTag in module 
Darcs.UI.Options.Matching. Is it OK ?
3/ Do we considere an implicit "and" between each group ?
4/ if not, add --or --and --not flags. But after the next problem is 
how to manage precedence without parenthesis ?
5/ Could we add a syntactic suggar for "tag" <=> match "tag XXX" ?

> 1/ hash (singular) exists but not hashes (plural). Is it OK ?

For hashes the match must always be exact (that's why you would use a
hash in the first place), so yes, plural makes no sense IMO.

2/ tag and tags come to the same options OneTag in module 
Darcs.UI.Options.Matching. Is it OK ?

I don't like it but this is how it works ATM. It is inconsistent at best
and misleading at worst. If it were my decision I would demote --tags to
an undocumented compatibility alias for --tag.

The real problem with --tag is that it is not an exact match by default.
I still think that regular expression matching for --tag is useless and
error prone. I have previously proposed a change in the UI but it was
voted down (IIRC) with the argument that the UI is more consistent as it is.

(To debunk the consistency argument: whenever I explain to casual darcs
users that --tag 2.1 is not enough you should use --tag '^2.1$' if you
want *exactly* version 2.1 because it might match the tag '2.1.1', they
shake their heads and stare at me in disbelief.)

3/ Do we considere an implicit "and" between each group ?

The groups I mentioned are not yet well-defined enough to make any
definite proposal based on them. There is --last and --index and so on
which do not fit this picture. Anyway, I think the general idea /
direction should go towards making all matching options mutually
exclusive. If you want to combine matchers, you can use a single match
with an elaborate match expression. That's what the --match etc are made
for.

4/ if not, add --or --and --not flags. But after the next problem is 
how to manage precedence without parenthesis ?

Exactly. And --match already supports all this. No need to repeat this
on the command line where we don't have the parsing capabilities etc.

5/ Could we add a syntactic suggar for "tag" <=> match "tag XXX" ?

It already is (AFAIK), no need to add anything.