On Sun, 14 Jan 2018 23:58:52 -0500, Matt Harbison wrote: > # HG changeset patch > # User Matt Harbison <matt_harbi...@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(). _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel