Path Pattern extension

[Marcin Kasperski]

Let it grow first a little bit. So far I have no clue whether current
code works on Windows (might be some backslashity-slashy replacements
will be needed), and whether any patterns more complicated than suffix
are to appear in real use cases (if so, some routes-like syntax to
distinguish greedy {pattern} from restricted one, or to regexpify
patterns may be needed). And there may be some bug, or conflict, or
sth (and initially it is easier for me to publish next fix, and for
people to install it, when it has it's own release cycle).

TL;DR: I wrote it yesterday and announced today. Let it grow a bit,
see users feedback, then let's return to the discussion about shipping
(say, early next year).

PS Poland just won against Ireland and is goint to Euro :-)))

On Sun, Oct 11, 2015 at 10:24 PM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
>
> On 10/11/2015 01:20 PM, Marcin Kasperski wrote:
>>
>> As I understand path_pattern is somewhat orthogonal to schemes extension.
>
>
> They are orthogonal in a similar space: making path handling simpler.
>
> [...]
>
>> Or, technically, schemes is about path syntax while path pattern is
>> about path definition propagation.
>>
>> Those two may happily cooperate (I haven't tested it, but path_pattern
>> should gladily propagate schemes-type paths), but in general I feel
>> those solve different (albeit related) needs. People may use both, or
>> may use just one of them.
>
>
> I think both approach are useful and solve different aspect of the same
> class of problem. You pattern maching approach is great and I would be happy
> to have it shipped with Mercurial. Adding it in it's own extensions seems
> superfluous as there is already another extension in the same area. That's
> why I'm pointing at the scheme extension.
>
> TL;DR; I like your idea, would be happy to ship it with Mercurial.
>
> --
> Pierre-Yves David