Not sure I fully comprehend the extdata thing. Is the RFC on the web?

Regarding a potential shell() directive, the benefit I am seeing is that it
would nicely nest with other directives. You would specify an input file
set, shell pipeline reading from stdin, as well as both input and output
delimiters (optional). A filter implementation (rather than my initial
per-file TRUE/FALSE proposal) would increase the throughput of some
expensive commands.

> Another concern is perm() can't be generic because of Windows.

Fair point.

Best regards

On Tue, Oct 18, 2016 at 4:55 PM, Yuya Nishihara <> wrote:

> On Mon, 17 Oct 2016 16:22:02 +0200, Marcus Harnisch wrote:
> > My intention was to extend the concept of fileset from the user
> > perspective. Providing a shell() directive, together with a
> [filesetalias]
> > section in the config file, would enable users to encapsulate complex
> shell
> > commands. This could be incredibly useful (would be for me anyway).
> Yeah, shell() or [extdata] 'shell:' would be useful.
> 2016-September/088426.html
> > In that case, a separate perm() directive would not even be necessary,
> > although still useful. I was merely suggesting it since having only
> exec()
> > seems arbitrarily incomplete from a user perspective.
> >
> > > Mercurial only cares for exec bit, so I don't think a generic perm()
> > function
> > > is a good idea.
> >
> > But users might care.
> Maybe. Another concern is perm() can't be generic because of Windows.
Mercurial mailing list

Reply via email to