[darcs-users] Re: problem in your darcs repo

[David Roundy]

[Moving from private email to darcs-users, since I noticed that I'm talking
about stuff that might be interesting to other users.]

On Sat, Apr 03, 2004 at 04:18:15PM -0500, Isaac Jones wrote:
> Is there a way to list tags on a repository?  I just used "darcs
> changes" and grep, but this seems somehow impure.

Hmmm.  No, there's no way to list tags.  This (like many other features) is
waiting on a nice way to specify search constraints.  I'd like to have a
unified interface for this, so you could restrict darcs changes (or other
commands) to tags, or to patches created by a given person, or patches
created within a date range or any logical combination of such operations
(e.g. patches created by droundy in May of last year).

I think the best way to do this is to come up with a mini-language,
something akin to that accepted by find, or by mutt (in its search terms)
or by aptitude (again when searching).  But I don't really care for any of
those examples, and would like a "clean" syntax with minimally obscure
behavior, and "normal" precedence and support for parentheses to group
expressions.

I guess I sort of imagine something like

darcs changes --matching 'author =~ droundy && date > "May 1, 2002" && date
< may 31, 2002'

I'm imagining that =~ (taken from perl) indicates matching a regular
expression, and we would also probably like to support == for exact
matches, and perhaps even some sort of a globbing match.  Obviously, we'd
also want to add an "is_tag" match, which would answer Isaac's original
question.

But of course, parsing such a language is a bit of a pain.  On the plus
side, doing so in haskell should be beautifully clean, as the parser can be
of type "String -> (PatchInfo -> Bool)", which should make things
reasonably pretty--at least we don't need to define a nasty tree data type
for the comparison itself once it is parsed.

One hangup (besides the fact that I don't like writing parsers) is that it
would also be nice to define checks on the *contents* of patches, rather
than just their metadata, e.g. to ask for changes that involve the removal
of directories.  I think this would need to be a separate sort of flag,
since we don't want to have to read the patch files if we can avoid it.  On
the other hand, maybe the parsed type of the --matching flag should be
something like "(PatchInfo, Maybe Patch) -> Bool", so that it could either
match on the metadata or the contents, and would only need to read the
contents (lazily) if the match requires them.  Hmmmm.  This sounds like the
best plan I've had so far.

If I had this --matching parsing code, it would be pretty easy to add
support for this flag in push, send, pull, apply and changes... probably
also in unpull, unrecord and rollback.  Adding support for it in record,
whatsnew and revert would require a bit more trickery, as those commands
would really only want to support matches on primitive patches, which have
no metadata.  We could also add support for matching in get and diff,
although it wouldn't be as nifty as in the other cases, because those
commands aren't interactive, so you'd probably have to know for certain
which patch will match the pattern you choose.  On the other hand, running
darcs get --matching "is_tag && name == 0.9.18" would definitely be handy.
-- 
David Roundy
http://www.abridgegame.org