[PATCH 5 of 5 RFC] lfs: control tracked file selection via a tracked file

[Yuya Nishihara]

On Sun, 14 Jan 2018 23:58:52 -0500, Matt Harbison wrote:
> # HG changeset patch
> # User Matt Harbison <matt_harbison at yahoo.com>
> # Date 1515971571 18000
> #      Sun Jan 14 18:12:51 2018 -0500
> # Node ID 3b651cef0884ad8108a19c6354d53103e378e12e
> # Parent  7e5d513b38c169856b51b6207d992abbef10d2d5
> lfs: control tracked file selection via a tracked file

(CC-ed Jun)

This generally looks good to me, though I haven't read it carefully.

> My initial thought was to read the file and change each "key = value" line into
> "((key) & (value))", so that each line could be ORed together, and make a single
> pass at compiling.  Unfortunately, that prevents exclusions if there's a
> catchall rule.  Consider what happens to a large *.c file here:
> 
>   [track]
>   **.c = none()
>   ** = size('>1MB')
>   # ((**.c) & (none())) | ((**) & (size('>1MB'))) => anything > 1MB
> 
> I also thought about having separate [include] and [exclude] sections.  But that
> just seems to open things up to user mistakes.  Consider:
> 
>   [include]
>   **.zip = all()
>   **.php = size('>10MB')
> 
>   [exclude]
>   **.zip = all()  # Who wins?
>   **.php = none() # Effectively 'all()' (i.e. nothing excluded), or >10MB ?
> 
> Therefore, it just compiles each key and value separately, and walks until the
> key matches something.

That make sense. Perhaps it is the same as encode/decode filters.

> I'm not sure how to enforce just file patterns on LHS
> without leaking knowledge about the minifileset here.  That means this will
> allow odd looking lines like this:
> 
>   [track]
>   **.c | **.txt = none()

It seems okay as an undocumented feature. We can instead extract a symbol/string
matcher from minifileset._compile().