Commit graph

5 commits

Author SHA1 Message Date
Yuya Nishihara
4474577ceb fileset: parse cwd/root-glob patterns
Mercurial appears to resolve cwd-relative path first, so "glob:*.c" could be
parsed as "**/*.c" if cwd was literally "**". It wouldn't practically matter,
but isn't correct. Instead, jj's parser first splits glob into literal part
and pattern. That's mainly because we want to parse the user input texts into
type-safe objects, and (RepoPathBuf, glob::Pattern) pairs are the simplest
ones. The current parser can't handle patterns like "foo/*/.." (= "foo" ?),
and errors out. I believe this restriction is acceptable.

Unlike literal paths, the 'glob:' pattern anchors to the whole file path. I
don't think "prefix"-matching glob is useful, and making it the default would
be rather confusing.
2024-04-18 11:09:54 +09:00
Yuya Nishihara
30984dae4a cli: if enabled, parse path arguments as fileset expressions
If this doesn't work out, maybe we can try one of these:
 a. fall back to bare file name if expression doesn't contain any operator-like
    characters (e.g. "f(x" is an error, but "f x" can be parsed as bare string)
 b. introduce command-line flag to opt in (e.g. -e FILESET)
 c. introduce pattern prefix to opt in (e.g. set:FILESET)

Closes #3239, #2915, #2286
2024-04-12 11:36:40 +09:00
Yuya Nishihara
a9694cba27 cli: add ui.allow-filesets to experiment with fileset/pattern syntax
The pattern syntax could be enabled unconditionally, but I want to fully
replace the ad-hoc pattern parsing function.
2024-04-12 11:36:40 +09:00
Yuya Nishihara
653173abad fileset: implement name resolution stage, add all()/none() functions
#3239
2024-04-09 20:42:09 +09:00
Yuya Nishihara
850887cf09 fileset: add basic pattern parsing functions
Naming convention is described in FilePattern::from_str_kind(). It's based
on Mercurial's pattern prefixes, but hopefully fixes some inconsistencies.
https://github.com/martinvonz/jj/issues/2915#issuecomment-1956401114

#3239
2024-04-07 19:43:29 +09:00