On 01/07/2017 08:56 AM, Yuya Nishihara wrote:
On Fri, 6 Jan 2017 21:29:43 -0500, Matt Harbison wrote:
On Jan 6, 2017, at 11:19 AM, Pierre-Yves David <pierre-yves.da...@ens-lyon.org>
wrote:
On 01/04/2017 07:04 PM, Matt Harbison wrote:
# HG changeset patch
# User Matt Harbison <matt_harbi...@yahoo.com>
# Date 1483550016 18000
# Wed Jan 04 12:13:36 2017 -0500
# Node ID 76d95ab94b9e206363629059fb7824002e19a9e5
# Parent 0064a1eb28e246ded9b726c696d048143d1b23f1
revset: introduce the summary predicate
This is similar to the 'desc()' predicate, however the search is limited to the
first line, which I couldn't figure out how to do with the existing
functionality. Unlike 'desc()', this supports regular expressions. The
'matching()' revset already treats the summary line distinctly from the full
description, but that finds similar revisions instead of searching with a
string.
Looks like a great usecase to handle, I want that. However, are there reasons
why:
1) We could not add full pattern support to desc()
2) We could not make this an extra keyworkd parameters of desc()
Multiplying the revset predicate hurts discoverability, having less but more
powerful predicate seems useful.
I share your concern about discoverability.
I started out editing desc(), but it's explicitly documented as case
insensitive. It seems confusing if matching for literals is case insensitive,
but regex is case sensitive for the same predicate. (I vaguely recall that you
can make regex case insensitive, but I think that would also surprise the
user.) I meant to mention that maybe we could add pattern support to desc() in
addition to this, but forgot. The other stuff I looked at that supports
patterns, like tag(), is case sensitive for both literals and regex. That
makes sense, since those search for identifiers.
Perhaps stringmatcher can have 3 types, icase literal, literal, and re, and
the default of desc() is icase literal for backward compatibility. You can
build a case-insensitive regexp object from a literal pattern.
https://docs.python.org/2/library/re.html#re.I
Yep, I think it is fine to have a desc() upgraded to more powerful
pattern. We must keep the default to "icase literal" but I don't see the
need to make the regex case insensitive with "desc". The user can
specify the case insensitivity flag to the regex if they needs it.
We just have to make sure to clearly document the case-insensitivity of
the default as it is different from most other revset with rich-pattern
matching.
I didn't consider #2, because of the issues with #1. Can you suggest a format
for this? I don't see any other ways to slice and dice the description, so it
kinda feels like the recently discussed boolean arg, i.e. the equivalent of:
list get_matches(char *str, bool summary_only);
I'm not strongly opposed to this;
If we get regexp support, we can probably easily build a regexp that
restrict search to the first line (but I've not checked what mode we use
by default so I' might be wrong). If regex fill this need we might
consider thats enough and we don't need anything else UI wise.
What do you think?
If you think something more explicit/user friendly is needed, I think a
boolean keywork-only argument restricting to firstline would do:
'desc(issue1337, firstline=True)'
(But if regexp seems good enough to you, I would rather stick to a
simpler UI, new predicate < new parameter < no parameter ;-) )
I care more about the functionality than the incantation. That said, there's
been some serious bikeshedding at work about whether bug markers belong at the
beginning or end of the summary. The argument for at the beginning seems to be
that it's easier to find by visually scanning each summary. I'd like to push
them towards the query tools, over eyeing things up. Simpler and more concise
will make it easier for the uninitiated. Of course, I could probably create a
shorter alias if needed.
(That part is more about your personal work-flow at work. We have been
using "issue tag in summary" for Mercurial and I think it works well in
most case and help when you scan the log. In practice that really
depends how you use that tags and what it means in your context.
The name make perfect sense when you think about it at first contact "summary" made me
though about "hg summary" and I was a bit confused about what this could do. I wonder if
we can have something better (but questions about desc seems more important first)
I can see that, but I don't have any better ideas. I mentioned the "summary"
field in the matching() predicate to point to prior art and consistency in the revset
arena.
Ha right, if "summary" is already used that way in a revset context the
name seems fine. Sorry for missing that.
Cheers
--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
